November 2003 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Proposal: United Dillo

by Paul Pelzl

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Melvin Hadasht

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Indan Zupancic

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

Nov. 20, 2003

Emacs (was: kbnav3 patch test)

by Sebastian Geerken

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

Nov. 20, 2003

Re: Re: [Dillo-dev] FLTK

by Melvin Hadasht

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

Nov. 20, 2003

Re: [Dillo-dev] FLTK

by Jorge Arellano Cid

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

Nov. 20, 2003

FORM:DICKSON M.

by MR Dickson Mubane.

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Jyri Jokinen

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Frank Gevaerts

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

Nov. 20, 2003

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

by Indan Zupancic

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

Nov. 20, 2003