- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Emacs

by Frank de Lange

Sebastian Geerken wrote: >>>(Emacs' use of tabs >>>messes up things sometimes, and the 2-space indent it uses are not >>>consistent with Dillo's conventions). >>> >>> > >Emacs users, put the following code into ~/.emacs: > >---------------------------------------------------------------------- >(defun array-find (a1 a2 &optional index-or-nil) > (let ((index (if index-or-nil index-or-nil 0)) > (l1 (length a1)) > (l2 (length a2))) > (if (> (+ index l2) l1) > nil > (let ((i 0)) > (while (and (< i l2) > (= (aref a1 (+ index i)) (aref a2 i))) > (setq i (+ i 1))) > (if (= i l2) > index > (array-find a1 a2 (+ index 1))))))) > >(defun my-c-hook () > (if (array-find (buffer-file-name) "/dillo") > (progn > ;; dillo conventions > (set-variable 'indent-tabs-mode nil) > (set-variable 'c-basic-offset 3)) > ;; conventions for other code > (set-variable 'indent-tabs-mode t) > (set-variable 'c-basic-offset 2))) > >(add-hook 'c-mode-hook 'my-c-hook) > > Thanks... Makes it a bit easier to be Dillo-compliant... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 21, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Indan Zupancic

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

Nov. 20, 2003

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

by Frank de Lange

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Melvin Hadasht

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Indan Zupancic

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Jyri Jokinen

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Melvin Hadasht

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Paul Pelzl

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Melvin Hadasht

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

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Indan Zupancic

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

Nov. 20, 2003