- Dillo-dev - lists.mailman3.com

[Dillo-dev]Meta-refresh warning

by Glyn Kennington

While using dillo to check some pages for AnyBrowser-friendliness, I've encountered the warning inserted whenever a <meta http-equiv="refresh" ...> tag is used. I interpreted this as meaning that the HTML I'd written was in some way wrong, and I should find another way to achieve the same effect. The warning says: This page uses the NON-STANDARD meta refresh tag. The HTML 4.01 SPEC\n" " (sec 7.4.4) recommends explicitly to avoid it. I checked that part of the HTML spec to see exactly what it said, and whether it suggested any better alternatives. However, all that section has to say about the use of "refresh" is: ( http://www.w3.org/TR/html401/struct/global.html#h-7.4.4 ) Note. Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. Authors should not use this technique to forward users to different pages, as this makes the page inaccessible to some users. Instead, automatic page forwarding should be done using server-side redirects. My understanding of that paragraph is that it's only recommending against redirection, in which the refresh tag specifies that a different page should be loaded after the timeout. It might additionally mean that it's only discouraged for "instant" (ie. delay=0) redirection. OTOH, refreshing the same page (which is what I'm trying to do with the page that I'm writing) should be OK. In this case, shouldn't dillo only complain if the "content" part of the tag contains a "URL=" (even if it won't handle the refresh without the aid of the meta-refresh patch)? I can write the necessary trivial patch to insert such a check if people agree that it's The Right Thing, but I thought I'd better check that I've interpreted the spec properly (and am reading the right bit of it) before I do so. Glyn

July 3, 2005

Re: [Dillo-dev]dillo on sparc64

by Damien COUDERC

Hi, i still have problems with latest release of dillo on sparc64. I have no more time to waste on this problem so i'm stopping my porting effort for OpenBSD. If you want to fix the problem just look at the following: $ dillo & [1] 5810 $ Nav_open_url: Url=>about:splash< Nav_open_url: Url=>dpi:/bm/< dpi_socket_dir.c:62: tst_dir: access : No such file or directory - /tmp/mips-uonqpe/ debug_msg - init_sockdir: The socket directory /tmp/mips-uonqpe does not exist or is not a directory dpid started Capi_dpi_conn_timeout:: try 1 main.c:154: get_command: dpid tag is NULL : main.c:328: main: get_command failed : bookmarks.dpi (v.13): accepting connections... [fopen]: No such file or directory Dpi_parse_token: [<ÐÐÐÐÐÐÐÐÐÐÐÐÐÐÐsend_page' url='dpi:/bm/'>] [sock_handler_write]: Broken pipe [1] + Segmentation fault dillo (core dumped) Good luck for your project, Damien

July 3, 2005

Re: [Dillo-dev]small question about TagInfo in html.c

by Jorge Arellano Cid

On Sat, Jul 02, 2005 at 09:17:20PM +0200, Wim De Smet wrote: > On 7/2/05, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > On Sat, Jul 02, 2005 at 02:57:49PM +0200, Wim De Smet wrote: > > > Hey, > > > > > > What exactly do the EndTag en TagLevel fields in the TagInfo struct > > > stand for? I was going to add the "q" function but I'm not sure what I > > > should fill in here. (and it wasn't directly clear from the otherwise > > > excellent src docs). > > > > EndTag holds whether the end tag of the HTML element is > > "Required", "Optional" or "Forbidden" as of the HTML 4.01 SPEC. > > > > TagLevel is a number that is used to heuristically parse bad > > HTML (it overrides the HTML SPEC a bit). The comment over > > Html_tag_cleanup_at_close() explains this. > > > > In a nutshell, a higher TagLevel allows the closing element's > > tag to close intermediate open tags, in the parsing stack, with > > lower TagLevel. > > > > Just use 2 as the value! :-) > > Okay then. But does this make it possible that the function for the > close tag is then called twice? The way I'm trying to get the q to > render now is just adding in an open tag and a close tag function and > calling a_Dw_page_add_text from both. The problem being that the text > seems to be added twice at the end. Related, I presumed that for > add_text I have to alloc the string but not dealloc it. Is this > correct? Call a_Dw_page_add_text from open tag only. Close tag is mainly for cleanups. > Still mucking about a bit. ;-) Look at some other simple elements. There're plenty of examples in html.c. -- Cheers Jorge.-

July 2, 2005

Re: [Dillo-dev]small question about TagInfo in html.c

by Wim De Smet

On 7/2/05, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Sat, Jul 02, 2005 at 02:57:49PM +0200, Wim De Smet wrote: > > Hey, > > > > What exactly do the EndTag en TagLevel fields in the TagInfo struct > > stand for? I was going to add the "q" function but I'm not sure what I > > should fill in here. (and it wasn't directly clear from the otherwise > > excellent src docs). > > EndTag holds whether the end tag of the HTML element is > "Required", "Optional" or "Forbidden" as of the HTML 4.01 SPEC. > > TagLevel is a number that is used to heuristically parse bad > HTML (it overrides the HTML SPEC a bit). The comment over > Html_tag_cleanup_at_close() explains this. > > In a nutshell, a higher TagLevel allows the closing element's > tag to close intermediate open tags, in the parsing stack, with > lower TagLevel. > > Just use 2 as the value! :-) Okay then. But does this make it possible that the function for the close tag is then called twice? The way I'm trying to get the q to render now is just adding in an open tag and a close tag function and calling a_Dw_page_add_text from both. The problem being that the text seems to be added twice at the end. Related, I presumed that for add_text I have to alloc the string but not dealloc it. Is this correct? Still mucking about a bit. ;-) greets, Wim

July 2, 2005

Re: [Dillo-dev]small question about TagInfo in html.c

by Jorge Arellano Cid

On Sat, Jul 02, 2005 at 02:57:49PM +0200, Wim De Smet wrote: > Hey, > > What exactly do the EndTag en TagLevel fields in the TagInfo struct > stand for? I was going to add the "q" function but I'm not sure what I > should fill in here. (and it wasn't directly clear from the otherwise > excellent src docs). EndTag holds whether the end tag of the HTML element is "Required", "Optional" or "Forbidden" as of the HTML 4.01 SPEC. TagLevel is a number that is used to heuristically parse bad HTML (it overrides the HTML SPEC a bit). The comment over Html_tag_cleanup_at_close() explains this. In a nutshell, a higher TagLevel allows the closing element's tag to close intermediate open tags, in the parsing stack, with lower TagLevel. Just use 2 as the value! :-) -- Cheers Jorge.-

July 2, 2005

[Dillo-dev]small question about TagInfo in html.c

by Wim De Smet

Hey, What exactly do the EndTag en TagLevel fields in the TagInfo struct stand for? I was going to add the "q" function but I'm not sure what I should fill in here. (and it wasn't directly clear from the otherwise excellent src docs). TIA, Wim

July 2, 2005

[Dillo-dev]cookies dpi over https and dpi framework

by Diego Sáenz

Hello, now that i have some free time i want to test the cookies dpi over https like Jorge suggested. I need the server so i ask to the webmaster if he can mount some https pages with cookies for the test, like Jorge suggested too. About other things and thinking about the future, i have some ideas about DPI framework and DPIs that can be useful, maybe. Register and init DPIs I think that the way that gives more adventages is to let dpid manage this using dpidrc to store the list of available DPIs(updated each time dpid is runned with the installed DPIs in the system and in the HOME/.dillo/dpi directory), and the metadata about DPIs: mime types or protocol that manages that DPI, menu entries or buttons that DPIs need and the more important if a user wants use(enabled) that DPI or not(disabled) dpidc need new commands (enable, disable, list DPIs) and individual register of DPIs(dpidc register directory/where/the/new/DPI/is) When a new DPI is register dpid run the DPI and ask the DPI metadata which a new DPI command(<dpi cmd='give_metadata'> ?) and the DPI returns the metadata in a text key-value format, for example a dpi that converts rtf and pdf files to html can send postfix_understand=rtf,pdf mime_understand=text/x-rtf,text/x-pdf (with the right mime type of course) After this dpid stores the metadata in dpidrc file. For example: DPI=rtf_pdf_viewer state=enabled or disabled or ... postfix_understand=rtf,pdf mime_understand=text/x-rtf,text/x-pdf And now three ways to get the new metadata in dillo or the DPIs that understand them: 1) The pasive solution. when a DPI start it read the dpidrc searching the metadata that it understand. (A DPI that manages mime types, so dillo do not need to do it, can make a list with the name and mimes that understand each DPI) 2) Active, but silly one. Dpid re-send the metadata to each other DPI, with a new DPI command, and each DPI redo his internal state with the metadata it understand. This is the worst solution because dpid need to run all DPIs to be sure that metadata arrives to the right DPI. 3) The complex and flexible solution, my prefered one. There is a key-value(send_me) in the DPIs metadata to register keys of metadatas. Dpid understand this key(send_me) and have a internal list to send the metadatas to the right DPI. If a DPI send a key registered with the send_me key while registering, dpid sends the change to the DPI that registered that key so it can update its internal data, caches, whatever. Example: A mime DPI manages the files with mime types unknows to dillo. When it register send this metadata and is stored in dpidrc like part of its metadata send_me=mime_understand Then after the rtf_pdf_viewer DPI is registered, and if it is enabled, dpid send to the mime DPI the DPI=rtf_pdf_viewer mime_understand=text/x-rtf,text/x-pdf and mime DPI updates its state so it can call rtf_pdf_viewer when find a rtf or pdf file. Pros: - It is so flexible that new keys and resources can be used by new DPIs while dpid, or even dillo in some case, do not need to be updated to understand it. - Do not need to modify dillo internals or few Cons: - Dpid, dpidc and DPIs need to be modified - And more, sure Protocols and mime DPIs Based in the xproto DPI i think that a DPI can manage all the protocols and mime formats that dillo do not understand. Dillo simply passes the url or stream(or file location) to that DPI when it do not understand the format and the DPI using a list call the right DPI, script, wathever to manage it. That last DPI open an app, return a data in format that dillo understand(html, gif, jpg, png), etc. Image/objets html tags can call the protocol_and_mime_DPI, with some care and a especial dpi tag, so new formats can be viewed in dillo, if a DPI converts them to formats understanded by dillo, in the right place in the page. A interesting idea is to can embed apps, like sylpheed embed dillo, in the space of a image or object with new tags and/or pasing the WID. The protocol_and_mime_DPI send a html page to dillo when there is more than a DPI or action, download included, for a protocol or mime to ask the user what to do, set default action, etc Pros: - All code is outside dillo - Compatible with all Cons: - Can need news dpi tags - And more, sure HTML GUI When dillo support frames(The only think because i do use an old dillo 0.8.0 patched with frames sometimes is because it have frames)/iframe/objects(this tag can include html to, but frames are better) the dillo GUI can be a html page, with a iframe that contains the viewed web page, and a DPI that modifies the GUI html page. The new thing is that the DPI can use a cache file with that html page that dillo loads at start so dillo init is as fast as now, only loading the DPI when needed. All DPIs that generate html must use the same CSS so all have the same look. Pros: - Make dillo core small - Look is fully configurable - DPIs can register menus and buttons and dillo do not need even to know or have the list of buttons or menus registered in mem an in each dillo Cons: - Need to add remote control dpi tags to dillo - And more, sure Adding all Only frames, and new dpi tags need to be done in dillo core and it gives, when the DPIs needed and dpid are done, a very flexible interface to cordinate DPIs and for example that the DPIs GUI elements can be implemented step by step based on funcionality without touching dillo internals and not all at same modifing dillo core or doing it unestable. Only some ideas. If somebody wants to disscuss them, destroy them, blame about my english or me and my sleep state at this time i have my e-mailbox and eyes open to read all of them. Diego Sáenz/DarkSpirit.

June 25, 2005

Re: [Dillo-dev]dillo-0.8.5.tar.bz2

by Liam J. Foy

On Fri(17)/Jun/05 - , Jorge Arellano Cid wrote: > Hi there! > > Well, everything is ready for the official announcement of the > newest release of dillo (v. 0.8.5). I'll post in freshmeat > tomorrow in the morning. > > BTW, I included a GPG signature for this release, so please > remember to pick my new key (available from Authors page or from > a keyserver) if you want to verify it. > > > -- > Cheers > Jorge.- > Lovely work Jorge & Team! -- - Liam J. Foy liamfoy(a)sepulcrum.org

June 19, 2005

[Dillo-dev]dillo-0.8.5.tar.bz2

by Jorge Arellano Cid

Hi there! Well, everything is ready for the official announcement of the newest release of dillo (v. 0.8.5). I'll post in freshmeat tomorrow in the morning. BTW, I included a GPG signature for this release, so please remember to pick my new key (available from Authors page or from a keyserver) if you want to verify it. -- Cheers Jorge.-

June 18, 2005

Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Riccardo Mottola

Hey, > The release candidate one tarball for 0.8.5 is ready for > testing. Please get it from: > > http://www.dillo.org/download/dillo-0.8.5-rc1.tar.bz2 for the first time I'm trying to compile on irix 6.5 (using gcc 2.95). 1. there are some header problems. By default IRIX installs only libjpeg and zlib binaries and not headers. And no libpng. So a common solution is to install packages for them, in /usr/freeware (if distributed by sgi) or /usr/nekoware (if from a common packager) where glib and gtk reside too. But having two different libraries is tricky since the wrong can be detected at runtime, etc etc... Also, there are no configure options for setting zlib and png places, but only right now I just played Making all in IO gcc -I/usr/freeware/include/gtk-1.2 -I/usr/freeware/include/glib-1.2 -I/usr/freeware/lib32/glib/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -L/usr/freeware/lib32 -L/usr/local/lib -o dillo -pthread chain.o commands.o cache.o capi.o dw.o dw_aligned_page.o dw_bullet.o dw_button.o dw_container.o dw_embed_gtk.o dw_ext_iterator.o dw_gtk_scrolled_frame.o dw_gtk_scrolled_window.o dw_gtk_statuslabel.o dw_gtk_viewport.o dw_hruler.o dw_image.o dw_list_item.o dw_marshal.o dw_page.o dw_style.o dw_table.o dw_table_cell.o dw_tooltip.o dw_widget.o findtext.o selection.o web.o progressbar.o dillo.o bookmark.o dicache.o dns.o gtk_ext_button.o gtk_ext_menu.o gtk_ext_menu_item.o gtk_menu_title.o gif.o jpeg.o png.o html.o image.o misc.o interface.o history.o nav.o plain.o menu.o prefs.o colors.o bitvec.o klist.o strbuf.o url.o cookies.o dpiapi.o IO/libDio.a -L/usr/freeware/lib32 -lgtk -lgdk -lgmodule -lglib -lintl -lXi -lXext -lX11 -lm -lz gcc: unrecognized option `-pthread' ld32: WARNING 84: /usr/freeware/lib32/libz.so is not used for resolving any symbol. ld32: ERROR 33: Unresolved text symbol "pthread_cancel" -- 1st referenced by IO/libDio.a(IO.o). I changed -pthread in -lpthread wherever I could... and I was told that ld32: WARNING 84: /usr/lib32/libpthread.so is not used for resolving any symbol. ld32: WARNING 84: /usr/freeware/lib32/libz.so is not used for resolving any symbol. ld32: ERROR 33: Unresolved text symbol "pthread_cancel" -- 1st referenced by IO/libDio.a(IO.o). the "not used for resolving" is deceiving on irix sometimes. for now I have no further solution cheers, Riccardo

June 17, 2005

Re: [Dillo-dev]RPMs

by Kelson Vibber

On Thursday 16 June 2005 5:53 pm, Patrick Shanahan wrote: > SuSE 9.0 here: > ... Thanks! Anyway, I've got the main ones up. My UML collection is semi-trashed, so I couldn't get any of the really old distros built, and I'm running into problems with autoconf (or maybe automake, I can't remember) on Mandrake 10.0 and older (but fortunately the 10.1 RPM runs on 10.0). I'll try to find some time on the weekend to track down the autoconf issue and see if I can work out the problems with UML. Building from the final tarball should help. Done: Fedora 1-4 Red Hat 7, 9 SuSE 9.0, 9.1, 9.2 Mandrake 10.0, 10.1 Yellow Dog 3, 4 -- Kelson Vibber www.hyperborea.org

June 17, 2005

Re: [Dillo-dev]RPMs

by Kelson Vibber

Jorge Arellano Cid wrote: > Unless somebody reports an error, I plan to officially announce > it tomorrow. Now, if you need some extra time to prepare the > RPMs, just let me know to delay it a bit. ;) I should be able to get most of them done tonight. I will have to drag a machine out of the closet and disconnect an I/O card, but that shouldn't take too long. And I've already upgraded the processor and board on that box, so builds should go faster than they used to. The main obstacle is that I'm a version behind on Mandriva and SuSE. I'm up to Mandrake 10.1 and SuSE 9.2. I do have a set of ISOs for Mandriva 2005 LE, but I don't know if I'll have time to install them tonight. I should definitely be able to get the following: Fedora Core 4 (already built) Fedora Core 3 Red Hat 9 (already built) Red Hat 7.3 Mandrake 10.1 SuSE 9.2 Yellow Dog 4 I'll get as many others built as I can, and some of these should work on multiple versions. Builds on Fedora 1-3 have been interchangeable so far, for instance, and I don't expect that to change. I will probably start dropping some of the older, EOL'ed distributions at some point. It's getting to be a pain to manage them all. -- Kelson Vibber www.hyperborea.org

June 17, 2005

Re: [Dillo-dev]Re: Some patch files for Korean, Russian and Japanese

by higuita

On Thu, 16 Jun 2005 11:35:52 +0800, "liou xiao" <liouxiao(a)hotmail.com> wrote: > Maybe FLEK-based dillo will solve it... that is the idea... fltk will have utf-8 and other goodies that gtk1 dont have, so enabling dillo to grow in features and not in size (as gtk2) higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

June 16, 2005

[Dillo-dev]RPMs

by Jorge Arellano Cid

Hi Kelson, If you want to build RPMs, it looks like rc1 will become 0.8.5 so you only need to change configure.in: -AM_INIT_AUTOMAKE(dillo, 0.8.5-rc1) +AM_INIT_AUTOMAKE(dillo, 0.8.5) Unless somebody reports an error, I plan to officially announce it tomorrow. Now, if you need some extra time to prepare the RPMs, just let me know to delay it a bit. ;) -- Cheers Jorge.-

June 16, 2005

Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Roberto A. Foglietta

Jorge Arellano Cid wrote: > Hi there, > > The release candidate one tarball for 0.8.5 is ready for > testing. Please get it from: > > http://www.dillo.org/download/dillo-0.8.5-rc1.tar.bz2 > > This code has had a lot of testing so emphasis is on the > build/compile process on the different platforms and on the file > dpi. The file dpi now reacts to 'dpidc stop' and also to the > DpiBye command issued by dpid after one hour of idleness. > > Please report back how it works so it can be released quickly. > On Mandriva LE 2005 (ex-Mandrake 10.2) compile and works without any problem. Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

June 16, 2005

[Dillo-dev]Re: Some patch files for Korean, Russian and Japanese

by liou xiao

Hi, I use a similar patch for visiting Chinese site. But I found such patch works only for some double-byte website, whose encoding is UTF-8; and lots of double-byte site still can't be rendered correctly, :( Maybe FLEK-based dillo will solve it... Best, LiouXiao ------------------------------ >Hi, > >I've prepared some patch files for other languages except European (LATIN-1). > >These patch files work fine with some other languages including Korean, Russian, and >Japanese than European languages(LATIN-1). These patches work well with dillo 0.80.4 >to 0.80.5-pre (CVS). > >If it is looked good as you see, please change the link on your web site as follow: > >http://myhome.naver.com/~ziolo/dillo_patch.html > >I hope these small patch files help someone to enjoy dillo. > >Sincerely, > >Ziolo > > > >PS. >I’m not professional computer programmer, so I’ll be pleasured if next dillo would supports >other languages including my own language (Korean) in main source stream >------------------------------------------------------------------------ >匙捞滚 :: 度! 家府唱霸官诧匙捞滚皋老阑父唱焊技夸. >http://mail.naver.com/ > _________________________________________________________________ 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com

June 16, 2005

Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Russell J. Wood

On Wed, Jun 15, 2005 at 12:24:17PM -0400, Jorge Arellano Cid wrote: > Hi there, > > The release candidate one tarball for 0.8.5 is ready for > testing. Please get it from: > > http://www.dillo.org/download/dillo-0.8.5-rc1.tar.bz2 > > This code has had a lot of testing so emphasis is on the > build/compile process on the different platforms and on the file > dpi. The file dpi now reacts to 'dpidc stop' and also to the > DpiBye command issued by dpid after one hour of idleness. > > Please report back how it works so it can be released quickly. Runs well on FreeBSD 5.3-R-p5. - Russell

June 16, 2005

Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Henrique Mayer

Hello! Build fine in Slackware 10.1, glibc 2.3.4, OpenSSL 0.9.7e, gtk+ 1.2.10. and the dpid stop on 1 hour after idle \o/ PS: Which is the reason to have a -Wno-unused-parameter in CFLAGS? Those unused parameters are realy unused?!? Can I clean it? Thanks. ,----[ Citando Jorge Arellano Cid <jcid(a)dillo.org> ]---- |Hi there, | | The release candidate one tarball for 0.8.5 is ready for |testing. Please get it from: | | http://www.dillo.org/download/dillo-0.8.5-rc1.tar.bz2 | | This code has had a lot of testing so emphasis is on the |build/compile process on the different platforms and on the file |dpi. The file dpi now reacts to 'dpidc stop' and also to the |DpiBye command issued by dpid after one hour of idleness. | | Please report back how it works so it can be released quickly. | |-- | Cheers | Jorge.- | |_______________________________________________ |Dillo-dev mailing list |Dillo-dev(a)dillo.org |http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- | $> cd /pub | $> more beer | -----BEGIN GEEK CODE BLOCK----- | Version: 3.12 | GU d- s+: a--- C++(+++) *L++ P(+) L+++ E W+++ N o K- w--- O-- M@ | V- PS+ PE Y(+) PGP- t+(++) 5 X+++ R+(++) tv-- b++(+++) DI++ D++ | G e+(++) h-- r y+ | ------END GEEK CODE BLOCK------ `---------------------------------------------------------------[]--

June 15, 2005

Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Johannes Hofmann

On Wed, Jun 15, 2005 at 02:18:45PM -0400, Jorge Arellano Cid wrote: > On Wed, Jun 15, 2005 at 06:56:40PM +0200, Johannes Hofmann wrote: > > Hi, > > > > here on DragonFly BSD, the GTK dialogs (e.g. "Open URL") have very small > > buttons without the usual text (no "OK", "Clear", "Cancel"). > > With previous versions, I didn't see this problem. > > There's no new code on this area; i.e. it's the same as with > 0.8.4. Try compiling 0.8.4. > You are right. 0.8.4 has the same problem here and so has a freshly compiled 0.8.3 and 0.8.2 ... On the othe hand I am running a previously compiled 0.8.3 which works fine. So it has nothing to do with the dillo source, but rather with my environment (gtk installation perhaps?). Sorry for the noise. Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

June 15, 2005

Re: [jcid@dillo.org: Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2]

by Brian Hechinger

On Wed, Jun 15, 2005 at 02:16:14PM -0400, Jorge Arellano Cid wrote: > > It's the same code as in 0.8.4, so you may try Sun compiler's > documentation. Maybe separating "fmt..." as "fmt ...". I don't > know. i'll give that a shot. > Although feedback is welcome, as 0.8.4 had this same code, the > release process continues. has anyone built 0.8.4 with Sun's C compiler? -brian -- "I fear death only slightly more than I hate my life." --8-bit Theater

June 15, 2005

[Dillo-dev]Re: dillo-0.8.5-rc1.tar.bz2

by Jorge Arellano Cid

On Wed, Jun 15, 2005 at 10:45:44AM -0700, Brian Dushaw wrote: > I am pleased to report that dillo-0.8.5-rc1.tar.bz2 > configures, compiles and installs without a problem > on the Psion netBook (strongarm 1100 cpu). > > I did not thoroughly test its functionality, but dillo > still crashes when it is used as an image viewer in > picturebook style browsing of image files. "Segmentation > fault" is reported. The webpages are: > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > <html> > <head> > <title>Title</title> > </head> > <body> > <a href="page349.html">Previous</a>    > <a href="page351.html">Next</a><br> > <center><img src="picture350.jpg" width=278 height=430><br></center> > <a href="page349.html">Previous</a>    > <a href="page351.html">Next</a> > </body> > </html> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > to allow one to scroll through the pictures. But after > several pictures, dillo crashes. > > B.D. Do you have a web URL with the crashing page? Just to know whether this is a general bug or platform specific. -- Cheers Jorge.-

June 15, 2005

Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Jorge Arellano Cid

On Wed, Jun 15, 2005 at 06:56:40PM +0200, Johannes Hofmann wrote: > Hi, > > here on DragonFly BSD, the GTK dialogs (e.g. "Open URL") have very small > buttons without the usual text (no "OK", "Clear", "Cancel"). > With previous versions, I didn't see this problem. There's no new code on this area; i.e. it's the same as with 0.8.4. Try compiling 0.8.4. -- Cheers Jorge.-

June 15, 2005

[jcid@dillo.org: Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2]

by Jorge Arellano Cid

June 15, 2005

Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Patrick Shanahan

* Jorge Arellano Cid <jcid(a)dillo.org> [06-15-05 11:34]: > http://www.dillo.org/download/dillo-0.8.5-rc1.tar.bz2 > > This code has had a lot of testing so emphasis is on the > build/compile process on the different platforms and on the file > dpi. The file dpi now reacts to 'dpidc stop' and also to the > DpiBye command issued by dpid after one hour of idleness. > > Please report back how it works so it can be released quickly. built fine with and without ssl enabled on SuSE 9.0. ssl enabled rpm available with spec/source @ http://wahoo.no-ip.org/~pat/dillo-0.8.5-rc1.ssl.i686.rpm http://wahoo.no-ip.org/~pat/dillo-0.8.5-rc1.tar.bz2 http://wahoo.no-ip.org/~pat/dillo-0.8.5-rc1.ssl.src.rpm -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery

June 15, 2005

Re: [Dillo-dev]New developer info

by Jorge Arellano Cid

On Tue, Jun 14, 2005 at 02:36:19PM +0200, Wim De Smet wrote: > Hi, Hi Wim! > [...] > I was thinking about doing some simple kind of plugin to get started > (are there any you want to work on?), but I'm fascinated with parsers > and how they work, though I might not be very good at writing them, > I'd be interested in working on that later on. Unfortunately my C > skills aren't very good but I've got the basics and I also know lots > of java (pretty useless here I guess :), some C++, and have experience > scripting in shells and python. > > cheers, > Wim OK. I think the easiest one is BUG#343 (parser related). On the side of dpis, I think a man-page-to-html filter can be interesting. This is something that lets you view man pages as html in the browser. It can be evolved to also handle "info" files and then become a good help browser, making an easy&quick interface to local information (in the harddisk). These days, GNU/Linux, BSD*, etc. distributions come with lots if information in different formats that is seldom used. This is man pages, info files, html files etc. if a dillo dpi can provide for an easy interface for accesing it, I think it would be very handy. Think of a single text entry that searches in the local HD for information ao a keyword[s] providing some local links as answer. > [Drasko wrote:] > Thanks for your replies and warm welcome. > I have experience in C, C++ and Java, and I am learning GTK+ and > Python at the moment. I would like something simle to start on gently, > as my skills are not qute high. I have no special preferencies, so > I'll agree with anything that you consider appropriate for beginer. > It would be nice to have some point-outs about the subject given (how > to start and where to look for the docs). Well, I meant something more specific about expertise. For instance: libc, pthreads, sockets, network programming, parsing, RFC implementations, protocols, widgets sets (as GTK/FLTK/Dw), non blocking IO, distributed programming, daemons, QA, testing, etc. :-) As with Wim, an easy one is BUG#343. On the cookies field, you can investigate/test BUG#364 and/or BUG#370 (got to coordinate with Diego S.). Another good one to start is BUG#674. A quick solution is trivial, but a good one requires a bit more of thinking and investigation to choose a good "cutting threshold" for the protection scheme. HTH. -- Cheers Jorge.-

June 15, 2005

Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Johannes Hofmann

Hi, here on DragonFly BSD, the GTK dialogs (e.g. "Open URL") have very small buttons without the usual text (no "OK", "Clear", "Cancel"). With previous versions, I didn't see this problem. Johannes On Wed, Jun 15, 2005 at 12:24:17PM -0400, Jorge Arellano Cid wrote: > Hi there, > > The release candidate one tarball for 0.8.5 is ready for > testing. Please get it from: > > http://www.dillo.org/download/dillo-0.8.5-rc1.tar.bz2 > > This code has had a lot of testing so emphasis is on the > build/compile process on the different platforms and on the file > dpi. The file dpi now reacts to 'dpidc stop' and also to the > DpiBye command issued by dpid after one hour of idleness. > > Please report back how it works so it can be released quickly. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

June 15, 2005

Re: [Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Brian Hechinger

On Wed, Jun 15, 2005 at 12:24:17PM -0400, Jorge Arellano Cid wrote: > Hi there, > > The release candidate one tarball for 0.8.5 is ready for > testing. Please get it from: > > http://www.dillo.org/download/dillo-0.8.5-rc1.tar.bz2 > > This code has had a lot of testing so emphasis is on the > build/compile process on the different platforms and on the file > dpi. The file dpi now reacts to 'dpidc stop' and also to the > DpiBye command issued by dpid after one hour of idleness. > > Please report back how it works so it can be released quickly. build on Solaris 9 with Sun's C compiler gets this error: Making all in IO gmake[3]: Entering directory `/mail/home/wonko/software/dillo-0.8.5-rc1/src/IO' source='mime.c' object='mime.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ cc -DHAVE_CONFIG_H -I. -I. -I../.. -fast -xtarget=ultra2i -xarch=v8plusa -I/usr/local/include -L/usr/local/lib -I/usr/local/include -I/usr/sfw/include/gtk-1.2 -I/usr/sfw/include/glib-1.2 -I/usr/sfw/lib/glib/include -fast -xtarget=ultra2i -xarch=v8plusa -I/usr/local/include -L/usr/local/lib -c mime.c "../msg.h", line 9: syntax error in macro parameters "../msg.h", line 10: syntax error in macro parameters "../msg.h", line 11: syntax error in macro parameters "../msg.h", line 14: syntax error in macro parameters "../msg.h", line 20: syntax error in macro parameters "../msg.h", line 25: syntax error in macro parameters "mime.c", line 151: warning: implicit function declaration: MSG_HTTP cc: acomp failed for mime.c gmake[3]: *** [mime.o] Error 2 gmake[3]: Leaving directory `/mail/home/wonko/software/dillo-0.8.5-rc1/src/IO' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/mail/home/wonko/software/dillo-0.8.5-rc1/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/mail/home/wonko/software/dillo-0.8.5-rc1' gmake: *** [all] Error 2 thoughts? clues? thanks. -brian -- "I fear death only slightly more than I hate my life." --8-bit Theater

June 15, 2005

[Dillo-dev]dillo-0.8.5-rc1.tar.bz2

by Jorge Arellano Cid

Hi there, The release candidate one tarball for 0.8.5 is ready for testing. Please get it from: http://www.dillo.org/download/dillo-0.8.5-rc1.tar.bz2 This code has had a lot of testing so emphasis is on the build/compile process on the different platforms and on the file dpi. The file dpi now reacts to 'dpidc stop' and also to the DpiBye command issued by dpid after one hour of idleness. Please report back how it works so it can be released quickly. -- Cheers Jorge.-

June 15, 2005

Re: [Dillo-dev]file.dpi patch

by Jorge Arellano Cid

On Wed, Jun 15, 2005 at 03:41:03PM +0200, Diego Sáenz wrote: > El Tue, 14 Jun 2005 09:19:53 -0400 > Jorge Arellano Cid <jcid(a)dillo.org> escribio: > > ... > > > One question to everybody: > > > > I have some code to make the file dpi react to DpiBye. This > > helps to not have a few orphaned file-dpi processes around, after > > some time of use (ps aux | grep file.dpi). > > > > Has anyone have this problem? Do you think is worth adding this > > last patch to dillo-0.8.5? > > > > I have that problem and think that it is worth. While the test > of the file.dpi path i needed to kill the file-dpi process all > the time after doing dpid stop when i reloaded the file.dpi. OK. I included the patch! (more on my next post). -- Cheers Jorge.-

June 15, 2005

Re: [Dillo-dev]file.dpi patch

by Diego Sáenz

El Tue, 14 Jun 2005 09:19:53 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: ... > One question to everybody: > > I have some code to make the file dpi react to DpiBye. This > helps to not have a few orphaned file-dpi processes around, after > some time of use (ps aux | grep file.dpi). > > Has anyone have this problem? Do you think is worth adding this > last patch to dillo-0.8.5? > I have that problem and think that it is worth. While the test of the file.dpi path i needed to kill the file-dpi process all the time after doing dpid stop when i reloaded the file.dpi. Diego Sáenz / DarkSpirit

June 15, 2005

Re: [Dillo-dev]New developer info

by Drasko Draskovic

Thanks for your replies and warm welcome. I have experience in C, C++ and Java, and I am learning GTK+ and Python at the moment. I would like something simle to start on gently, as my skills are not qute high. I have no special preferencies, so I'll agree with anything that you consider appropriate for beginer. It would be nice to have some point-outs about the subject given (how to start and where to look for the docs). Thanks and cheers, Drasko On 6/14/05, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi! > > On Sun, Jun 12, 2005 at 07:48:21PM +0200, Drasko Draskovic wrote: > > Hi all. I tried Dillo and I like it very much. I'd like to help it > > become better, so can anyone pint me out to some thing I can start to > > work? It would be yet hard for me to organize and decide where and how > > to start. So, if anyone have some thing specific to assign, I will be > > glad to help. > > Excellent. It's always good to have new developers. Welcome > aboard! > > Please let me know about your experience, strong areas of > development and interest spots to pick a good start task for you. > We have plenty of things to chose from! > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- Drasko Draskovic MSc Student in Computer Sciencies School of Electrical Engeneering University of Belgrade

June 14, 2005

Re: [Dillo-dev]file.dpi patch

by Jorge Arellano Cid

On Sun, Jun 12, 2005 at 04:19:04PM +0200, Diego Sáenz wrote: > Hi, i send a small patch to make the file.dpi a little more > intuitive than now. The patch make that when one person write > only "file:" in the dillo location bar it show the current > working directory, like previous dillo file: handlers, instead to > show nothing, like now. > > I have think all side effects that the changes can have and > test it. The patch is for the current cvs, but works in previos > dillo versions. OK, it's on CVS now and will be on 0.8.5. One question to everybody: I have some code to make the file dpi react to DpiBye. This helps to not have a few orphaned file-dpi processes around, after some time of use (ps aux | grep file.dpi). Has anyone have this problem? Do you think is worth adding this last patch to dillo-0.8.5? -- Cheers Jorge.-

June 14, 2005

Re: [Dillo-dev]New developer info

by Wim De Smet

Hi, I hope everyone will excuse me for posting in the same thread but it kind of seemed appropiate given the subject. I've also been playing around with dillo and I met Jorge and Sebastian at FOSDEM this year. Been lurking on the list for a while since I've got lots going on and didn't really have time. But as soon as I turn in my last exam this month I'd be happy to help out here or there. I was thinking about doing some simple kind of plugin to get started (are there any you want to work on?), but I'm fascinated with parsers and how they work, though I might not be very good at writing them, I'd be interested in working on that later on. Unfortunately my C skills aren't very good but I've got the basics and I also know lots of java (pretty useless here I guess :), some C++, and have experience scripting in shells and python. cheers, Wim

June 14, 2005

Re: [Dillo-dev]New developer info

by Jorge Arellano Cid

Hi! On Sun, Jun 12, 2005 at 07:48:21PM +0200, Drasko Draskovic wrote: > Hi all. I tried Dillo and I like it very much. I'd like to help it > become better, so can anyone pint me out to some thing I can start to > work? It would be yet hard for me to organize and decide where and how > to start. So, if anyone have some thing specific to assign, I will be > glad to help. Excellent. It's always good to have new developers. Welcome aboard! Please let me know about your experience, strong areas of development and interest spots to pick a good start task for you. We have plenty of things to chose from! -- Cheers Jorge.-

June 13, 2005

Re: [Dillo-dev]Viewing HTTP Headers with DPI

by Russell J. Wood

>> ... > Right now, you can tell Dillo to print the headers to stdout. > Go to Cache_get_header() and: > > - _MSG("Header [io_len=%d]\n%s", i, hdr->str); > + MSG("Header [io_len=%d]\n%s", i, hdr->str); Thanks for that, but is there also a way to print out client headers also? I've had a quick look, but I have to run to work now. - Russell

June 13, 2005

[Dillo-dev]New developer info

by Drasko Draskovic

Hi all. I tried Dillo and I like it very much. I'd like to help it become better, so can anyone pint me out to some thing I can start to work? It would be yet hard for me to organize and decide where and how to start. So, if anyone have some thing specific to assign, I will be glad to help. Best regards, Drasko -- Drasko Draskovic MSc Student in Computer Sciencies School of Electrical Engeneering University of Belgrade

June 12, 2005

[Dillo-dev]file.dpi patch

by Diego Sáenz

Hi, i send a small patch to make the file.dpi a little more intuitive than now. The patch make that when one person write only "file:" in the dillo location bar it show the current working directory, like previous dillo file: handlers, instead to show nothing, like now. I have think all side effects that the changes can have and test it. The patch is for the current cvs, but works in previos dillo versions. Diego Sáenz / DarkSpirit diff -pru dillo-cvs20051106-0.8.5-pre-DIRTY/dpi/file.c dillo-cvs20051106-0.8.5-pre-WORK/dpi/file.c --- dillo-cvs20051106-0.8.5-pre-DIRTY/dpi/file.c 2005-06-12 15:44:52.000000000 +0200 +++ dillo-cvs20051106-0.8.5-pre-WORK/dpi/file.c 2005-06-12 15:47:51.000000000 +0200 @@ -747,14 +747,15 @@ static char *File_normalize_path(const c return NULL; str += 5; - if (*str == '\0') - return NULL; /* Skip slashes */ while (str[0] == '/' && str[1] != '\0' && str[1] == '/') str++; - if (*str == '~') { + if (*str == '\0') { + /* Give CWD if the string is only "file:" */ + basename = g_get_current_dir(); + } else if (*str == '~') { if (str[1] == '\0' || str[1] == '/') { /* Expand 'tilde' to user's home */ basename = g_strdup(g_get_home_dir());

June 12, 2005

Re: [Dillo-dev]Viewing HTTP Headers with DPI

by Jorge Arellano Cid

On Thu, Jun 09, 2005 at 07:04:09AM +0800, Russell J. Wood wrote: > On Wed, Jun 08, 2005 at 12:46:19PM -0400, Jorge Arellano Cid wrote: > > On Wed, Jun 08, 2005 at 06:31:18AM +0800, Russell J. Wood wrote: > > > On Tue, Jun 07, 2005 at 05:13:11PM -0400, Jorge Arellano Cid wrote: > > > > On Sun, Jun 05, 2005 at 12:17:20PM +0800, Russell J. Wood wrote: > > > > > Hi all, > > > > > > > > > > Is it possible to view all request/response headers using DPI? > > > > > > > > That depends on the specific dpi. Please explain it further. > > > > > > Well, it's not for a specific DPI, I would like to know if it's possible to > > > get that information using DPI as if it is, I would like to write a plugin to > > > do it. > > > > > > It's just I didn't see much in the documentation about getting that information. > > > > Currently, dpip is not providing a dpi-command to request dillo > > for that info. Now, it can be done in a quite similar way that > > the cookies dpi (currently on testing) does. > > > > BTW, what for? (if not under NDA of course :) > > Great to hear it will be possible. just let me know when, and point me to the > documentation. =) > > I like to view HTTP Headers when I've developing web applications or, when I'm > just curious to know what's going on. Usually I use Firefox, but it's just so > damn slow! Right now, you can tell Dillo to print the headers to stdout. Go to Cache_get_header() and: - _MSG("Header [io_len=%d]\n%s", i, hdr->str); + MSG("Header [io_len=%d]\n%s", i, hdr->str); HTH. -- Cheers Jorge.-

June 10, 2005

Re: [Dillo-dev]Viewing HTTP Headers with DPI

by Russell J. Wood

On Wed, Jun 08, 2005 at 12:46:19PM -0400, Jorge Arellano Cid wrote: > On Wed, Jun 08, 2005 at 06:31:18AM +0800, Russell J. Wood wrote: > > On Tue, Jun 07, 2005 at 05:13:11PM -0400, Jorge Arellano Cid wrote: > > > On Sun, Jun 05, 2005 at 12:17:20PM +0800, Russell J. Wood wrote: > > > > Hi all, > > > > > > > > Is it possible to view all request/response headers using DPI? > > > > > > That depends on the specific dpi. Please explain it further. > > > > Well, it's not for a specific DPI, I would like to know if it's possible to > > get that information using DPI as if it is, I would like to write a plugin to > > do it. > > > > It's just I didn't see much in the documentation about getting that information. > > Currently, dpip is not providing a dpi-command to request dillo > for that info. Now, it can be done in a quite similar way that > the cookies dpi (currently on testing) does. > > BTW, what for? (if not under NDA of course :) Great to hear it will be possible. just let me know when, and point me to the documentation. =) I like to view HTTP Headers when I've developing web applications or, when I'm just curious to know what's going on. Usually I use Firefox, but it's just so damn slow! - Russell

June 8, 2005

Re: [Dillo-dev]Viewing HTTP Headers with DPI

by Jorge Arellano Cid

On Wed, Jun 08, 2005 at 06:31:18AM +0800, Russell J. Wood wrote: > On Tue, Jun 07, 2005 at 05:13:11PM -0400, Jorge Arellano Cid wrote: > > On Sun, Jun 05, 2005 at 12:17:20PM +0800, Russell J. Wood wrote: > > > Hi all, > > > > > > Is it possible to view all request/response headers using DPI? > > > > That depends on the specific dpi. Please explain it further. > > Well, it's not for a specific DPI, I would like to know if it's possible to > get that information using DPI as if it is, I would like to write a plugin to > do it. > > It's just I didn't see much in the documentation about getting that information. Currently, dpip is not providing a dpi-command to request dillo for that info. Now, it can be done in a quite similar way that the cookies dpi (currently on testing) does. BTW, what for? (if not under NDA of course :) -- Cheers Jorge.-

June 8, 2005

Re: [Dillo-dev]Viewing HTTP Headers with DPI

by Russell J. Wood

On Tue, Jun 07, 2005 at 05:13:11PM -0400, Jorge Arellano Cid wrote: > On Sun, Jun 05, 2005 at 12:17:20PM +0800, Russell J. Wood wrote: > > Hi all, > > > > Is it possible to view all request/response headers using DPI? > > That depends on the specific dpi. Please explain it further. Well, it's not for a specific DPI, I would like to know if it's possible to get that information using DPI as if it is, I would like to write a plugin to do it. It's just I didn't see much in the documentation about getting that information. - Russell

June 7, 2005

Re: [Dillo-dev]Access for end users for fltk dillo

by Jorge Arellano Cid

On Mon, Jun 06, 2005 at 05:14:49PM +0200, meka wrote: > Can we have something like this? I know it is not done yet, but there are some things I would like to see. For example, gcc-4.0 on amd64 treats this as an error > > void *tmp; > int i = (int)tmp; > > I would hate to have to debug it later, so it would be nice to > have fltk version od dillo while it is still "young", and try to > patch things. I do have both compilers, but sooner or later, > people will have to patch it on SuSE, Slackware or whatever > distro they have. Why not making it correct right now? Thanx. :o) Basically because we don't have a "young" tree yet; we have specific parts that we assemble and test isolated. We hope to have a tree shortly after LSM 2005. -- Cheers Jorge.-

June 7, 2005

Re: [Dillo-dev]Viewing HTTP Headers with DPI

by Jorge Arellano Cid

On Sun, Jun 05, 2005 at 12:17:20PM +0800, Russell J. Wood wrote: > Hi all, > > Is it possible to view all request/response headers using DPI? That depends on the specific dpi. Please explain it further. -- Cheers Jorge.-

June 7, 2005

Re: [Dillo-dev]Preparing the dillo-0.8.5 release.

by Kelson Vibber

Jorge Arellano Cid wrote: > Back to dillo-0.8.5: this release is mainly a bug-fix release. > The final touches were just uploaded to current CVS. Please > download it, test, and report back to the list on how it works. > This will help me to make the tarball and release it ASAP. Thursday's CVS seems to work fine here (Fedora Core 3 x86), and RPM didn't need any major changes. -- Kelson Vibber www.hyperborea.org

June 6, 2005

[Dillo-dev]Access for end users for fltk dillo

by meka

Can we have something like this? I know it is not done yet, but there are some things I would like to see. For example, gcc-4.0 on amd64 treats this as an error void *tmp; int i = (int)tmp; I would hate to have to debug it later, so it would be nice to have fltk version od dillo while it is still "young", and try to patch things. I do have both compilers, but sooner or later, people will have to patch it on SuSE, Slackware or whatever distro they have. Why not making it correct right now? Thanx. :o) -- Pinguin? Daemon? Fish? Dragon fly? Grow up. Windows are the future, daemons and animals are for fairy tales.

June 6, 2005

[Dillo-dev]Viewing HTTP Headers with DPI

by Russell J. Wood

Hi all, Is it possible to view all request/response headers using DPI? - Russell

June 5, 2005

Re: [Dillo-dev]Preparing the dillo-0.8.5 release.

by Thomas-Martin Seck

* meka (meka(a)softhome.net) > On Fri, 3 Jun 2005 12:06:03 +0200 > Thomas-Martin Seck <tmseck-lists(a)netcologne.de> wrote: > > > * Jorge Arellano Cid (jcid(a)dillo.org) > > > > Will FLTK2.0 be officially released by then? I'm asking because I can > > only update dillo to FLTK-dillo when we have a FLTK2 port in the FreeBSD > > ports tree. (I just looked and we don't even seem have FLTK 1.2 in > > there, only 1.1.6. Hm. Looks like work.) > I am working on a port, but don't know how to implement svn in fetch > (I know there is do-fetch). I just need to test few things. The main No need to do this; just fetch the latest snapshot and update the port once in a while regarding the snapshot revision. Since the snapshots seem to be kept for about 3 months you do not need to worry too much about the port becoming unfetchable. > problem is the error while compiling it with system compiler (gcc-4.1 > works just fine). Nice to hear! You should submit gcc related problems to the FLTK folks, though. FreeBSD will use gcc 3.4 on 5.x and 6.x for quite a while and I guess the other BSDs will follow suit. > I think I will finish it in about a month (I'm > really busy right now), and I don't think fltk-dillo will be released > soon (I hope I'm wrong :o). I'm looking forward to it! Regards, -- Thomas-Martin Seck

June 4, 2005

Re: [Dillo-dev]Preparing the dillo-0.8.5 release.

by Thomas-Martin Seck

* Jorge Arellano Cid (jcid(a)dillo.org) > > I'm asking because I can > > only update dillo to FLTK-dillo when we have a FLTK2 port in the FreeBSD > > ports tree. (I just looked and we don't even seem have FLTK 1.2 in > > there, only 1.1.6. Hm. Looks like work.) > > FLTK2 is much cleaner, and multiplatform, so it should'n be > that hard to port. BTW, can't you have a statically linked > FLTK2-based dillo in FreeBSD? This would work, I'll see what I can do. I'm doing a similar dance with Felix von Leitner's libowfat/gatling projects at the moment regarding library dependencies. I'll coordinate efforts with the current maintainer of FLTK 1.1.6. > > I managed to fetch a few minor updates around 0700 UTC -- the CVS server > > seems to have died after that. Could someone investigate? > > At least for me CVS is working now, as of this writting. Seems to have been a transient problem at wearlab.de; my mail took some time to be delivered to the list, too. > > What I got > > calls itself 0.8.5-pre and works as well as 0.8.4 on both FreeBSD 4 > > and 5 (i386). > > Yes, that's the one. I'm just to change 0.8.5-pre to 0.8.5 and > update the splash screen brief before packing the tarball for the > final test before public release. Ok, I just checked and I indeed got all changes. Looks OK for me. Regards, -- Thomas-Martin Seck

June 4, 2005

Re: [Dillo-dev]Preparing the dillo-0.8.5 release.

by meka

On Fri, 3 Jun 2005 12:06:03 +0200 Thomas-Martin Seck <tmseck-lists(a)netcologne.de> wrote: > * Jorge Arellano Cid (jcid(a)dillo.org) > > Will FLTK2.0 be officially released by then? I'm asking because I can > only update dillo to FLTK-dillo when we have a FLTK2 port in the FreeBSD > ports tree. (I just looked and we don't even seem have FLTK 1.2 in > there, only 1.1.6. Hm. Looks like work.) I am working on a port, but don't know how to implement svn in fetch (I know there is do-fetch). I just need to test few things. The main problem is the error while compiling it with system compiler (gcc-4.1 works just fine). I think I will finish it in about a month (I'm really busy right now), and I don't think fltk-dillo will be released soon (I hope I'm wrong :o). -- Pinguin? Daemon? Fish? Dragon fly? Grow up. Windows are the future, daemons and animals are for fairy tales.

June 4, 2005

Re: [Dillo-dev]Using dillo on SourceForge

by Diego Sáenz

El Fri, 3 Jun 2005 13:47:21 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > > On Thu, Jun 02, 2005 at 03:56:29AM +0200, Diego Sáenz wrote: > > Hello Jorge, i am the guy who make the path to move the dillo > > cookies code to a dpi. I want to know why is not the cookies > > dpi patch in the cvs? What must i do/change to see the code in > > the cvs? I use dillo with the cookies dpi patch every day and i > > have no complains.(I allow cookies for few sites anyway so i do > > not know if it is enought) > > CVS is about to be released as bugfix dillo-0.8.5. The idea is > to merge the new cookies dpi with the new dpi stuff in the fltk2 > tree. Now, as it could certainly help the debugging of this dpi, > I'll merge it into the 0.8.5 CVS after the release so the guys in > dillo-dev can help you with the testing&debugging. Ok, thanks by the fast answer. Can you advance something about the new dpi stuff? > > > About sourceforge thing it do not login or create new > > account(try to load(¿?) the submit url but do not do), but you > > can copy the cookies for the "remember me" option from another > > browser, while cookies.dpi is off, and use dillo normally. > > This would be interesting to investigate. I mean, what's > required to fully work with sourceforge (from a distance, it > looks like some HTTP1.1 tweaks can help). There are other websites in wich dillo do not logging or register(even sites that not use https for them), but after you copy the cookies you can use it. A feature to load(but not update) cookies files from others browsers, now that dillo uses netescape like cookies file, can be very easy to do in cookies dpi. > > > About test if the cookies work correctly over https i do not ... Goodbye

June 3, 2005