June 2005 - Dillo-dev - lists.mailman3.com

[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