Hello, With "united Dillo" I mean that there is always just one Dillo running per user, so when you start Dillo while it is already running, then the current one will open a new window. I made a patch as proof of concept, see: http://www.xs4all.nl/~dorinek/dillo This approach has two big advantages: 1) Always one Dillo has less overhead than running multiple instances at the same time. 2) Automatic synchronization/no need for synchronization anymore. First advantage is in the spirit of Dillo, wanting to be small, light and fast. Second advantage means that doing certain things will be much simpler, like having always cookies, no need to synchronize plugins, meaning that dpid is not really needed anymore, because most of the points from the problem list are solved (see Dpid.txt). Problems that aren't solved: * Forks can be expensive (Dillo had to fork its dpis). But dpid does much more than simply forking: it forks and then starts up an external program (which often also forks and starts up wget). Beside, if Dillo uses library plugins then there is no need to fork at all. * It increments dillo's core size. The patch adds about 70 lines of code to dillo.c and increases dillo with about 1 K. It is true that if you get rid of dpid then more code is needed in Dillo's core. But that's only moving the code to some other place, no real increase if you ask me. Having a seperate dpid has much more overhead at runtime (seperate process versus bigger executable). You can always make a plugin handling library, then it isn't part of Dillo's core. Of course a united Dillo has problems/disadvantages too: It is sometimes still needed to synchronize multiple windows. If it's not implemented carefully, you may lose functionality (aka command line options). 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. What do you think about it? Greetings, Indan
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
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.
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
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
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
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
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
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
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
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
Am Thu, Nov 20, 2003 at 10:59:47PM +0200 schrieb Jyri Jokinen und sprach:
On Thu, Nov 20, 2003 at 08:48:56PM +0100, Indan Zupancic wrote:
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.
I'm using fluxbox as well and still do use dillo-tabs heavily. Why? If you want to read 30 news messages in a seperate window (fast open- and closeable) I would have 30 additional window-manager tabs. With Frank's patch I do just open one window per news-site and every message in a new sub-tab. My open window-tabs still get clear i.e. <20 instead of having 50 mixed. So the can-be-done-with-window-manager-as-well argument doesn't really exist for me. Stephan
On Mon, Nov 24, 2003 at 12:12:49PM +0100, Stephan Goetter wrote:
I said "browser tabs". Window manager level window grouping is ok, and renders browser tabs useless. That was/is the point.
This stuff is on the way of becoming off topic to the list, please try to keep it attleast somewhat Dillo related if you reply (or reply off list).
I'm using fluxbox as well and still do use dillo-tabs heavily. Why?
I don't know. Because you are using a window manager with a bad implementation of the concept of window grouping?
With Frank's patch I do just open one window per news-site and every message in a new sub-tab. My open window-tabs still get clear i.e. <20 instead of having 50 mixed.
This by no means is impossible with window manager window grouping. Instead of having to nest windows, why don't you open a new group for different news sites? Also, can you move browser tabs around your browser windows, that are all around your viewports and workspaces, when it becomes necessary? About nesting - when is there enough? How deep do you want to dive, and when does it become unusable? Next you want subtabs to your web broser so you can "group what you are doing" better and better. Never did you consider of just opening different windows for those groups.
So the can-be-done-with-window-manager-as-well argument doesn't really exist for me.
I don't undestand why you insist using a window manager that doesn't do what you want, and you have to rely on application based extensions to do those things instead. Thus, there is code dublication and implementations that differ from application to application, multiplied configuration process needed for every application - oh, and probably twice the bugs too. This situation really can't be for the good of anyone. I'm somewhat sorry to see Dillo go tabs, even it serves some of the project goals (even those who are using a window manager they really don't want to use and can't change it for a reason or another have the bliss of tabs). I bet we get a kitchen sink too at some point for the same reasons (even those with no kitchen sink can see a kitchen sink). But I do think I've said this enough times allready. Please reply off the list if you have additional questions or points to make. -- shared, pekwm people
Just think about all those people that want to use Dillo in a kiosk running no window manager at all. ;)
participants (6)
-
Frank Gevaerts -
Indan Zupancic -
Jyri Jokinen -
Melvin Hadasht -
Paul Pelzl -
Stephan Goetter