samhain wrote:If it were so then it would have a long way to get there.

maybe and maybe not there might be specific problems never addressed in x11 specific qt4 code (though present in qt3-kde copy), eg like this: http://labs.trolltech.com/blogs/2009/06 ... ng-on-x11/

Ignacio Serantes wrote:On the other side, you have Firefox or Amarok. In both cases, you can find a lot of applications developed to increase Firefox and Amarok power that don't crash the host application, at least I never have this kind of crash.

Actually, that can happen. Granted, it's very rare but I have had it happen in both Firefox (current version) and Amarok (1.4 series so it may be fixed in 2.x. I've never had it happen there at any rate).

I don't remember which Amarok-extension that was the culprit but the firefox one was "NoScript". And I've had the flash-plugin bring down all of Chrome as well and not just the tab and/or the flash-playing ability. Then again, the Linux version of Chrome is still considered alpha isn't it?

Kryten2X4B wrote:Actually, that can happen. Granted, it's very rare but I have had it happen in both Firefox (current version) and Amarok (1.4 series so it may be fixed in 2.x. I've never had it happen there at any rate).

I don't remember which Amarok-extension that was the culprit but the firefox one was "NoScript". And I've had the flash-plugin bring down all of Chrome as well and not just the tab and/or the flash-playing ability. Then again, the Linux version of Chrome is still considered alpha isn't it?

As I told this never happens to me but I'm sure that Firefox and Amarok are not totally free of this kind of crashes, because there is no program without bugs.

And yes, I'm testing Chrome linux 64 alpha with flash player 64 alpha and I it's really stable, very much stable as Plasma or Konqueror and is really fast. I can be working hours and hours without any crash, sometimes flash plugin crash but Chrome don't. If things continue in this progression, Chrome will be the fastest and most stable browser in the market.

Ignacio Serantes wrote:Obviously I'm not a C++ neither has a big knowledge about Plasma or Konqueror but, in an application like Chrome you have elements, like a flash container, image containers, text, animated gifs and even video. All these element can be viewed as a kind of "plasmoids" because they are independent but inside Chrome, some elements can be resized, and change it's relative position if browser is resized but, if one of this elements crash, Chrome survives.

The difference is that in Chorme, the subprocesses share practically no information with each other. In plasma, they have to be able to share DataEngines, the canvas, themeing, alpha-blending, and a lot of other stuff. Plasma and Chrome are totally different things.

For Konqueror, I agree, it would be nice if Flash was a separate process, but since I don't know anything about how Flash is embedded, I can't really say anything on the complexity. Remember though, it's not really Konqueror's fault that Flash is a piece of shіt.

Ignacio Serantes wrote:On the other side, you have Firefox or Amarok. In both cases, you can find a lot of applications developed to increase Firefox and Amarok power that don't crash the host application, at least I never have this kind of crash.

You must have forgotten the memory leaks that plagued Firefox up until version 2.5. And there are still some innocent-looking extensions that leak memory. True, Firefox does not crash (much - Flash sometimes does manage to crash it), but that's because extensions are written in Javascript and XML. You can write Plasmoids in Javascript too, and they won't crash.

Ignacio Serantes wrote:Finally, we have Xorg. In Xorg many programs are working and sending signals about window positions and, when a running program crash, konqueror 4 and plasma are good examples, not all my Xorg session crashed.

Ignacio Serantes wrote:My question is simple, if programs like Xorg, Amarok, Firefox and Chrome exists it's perfectly clear that stability and powerful can be achieved so, why Konqueror 4 and Plasma was so unstable? What is the big advantage that Konqueror 4 and Plasma offer to us at cost of unstability?

Because software is not magic. If you knew how to program, you'd understand the complexity involved in masking a project both fast, flexible and reliable, especially if it is a large project.

Alec wrote:The difference is that in Chorme, the subprocesses share practically no information with each other. In plasma, they have to be able to share DataEngines, the canvas, themeing, alpha-blending, and a lot of other stuff. Plasma and Chrome are totally different things.

Well, I don't know anything about canvas, themeing, alpha-blending and other stuff but about data I know a few and this approach is not safe. But, seriously, dataengines are sharing gigabites of data per second to justify a single process? The samples I see are really simple and could be in other process with hight latency without problem. And don't forget that this was only a desktop and not critic real time information panel.

On the other side, all this stuff you talk about permits us doing what kind of things?. I test a few about plasmoids and, as far I can see I can't do anything from my plasmoid with another and I not sure what was the utility of doing that thing. Probably I misunderstood absolutely the Plasma objectives.

Alec wrote:For Konqueror, I agree, it would be nice if Flash was a separate process, but since I don't know anything about how Flash is embedded, I can't really say anything on the complexity. Remember though, it's not really Konqueror's fault that Flash is a piece of shіt.

Blame flash player is a boring and recurring explanation about Konqueror 4 crashes. Flash was the biggest piece of **** ever developed but works with other browsers without as many problems as with Konqueror 4. What happens?, Opera, Firefox, IE and Chrome developers are better than Konqueror developers?

Alec wrote:You must have forgotten the memory leaks that plagued Firefox up until version 2.5. And there are still some innocent-looking extensions that leak memory. True, Firefox does not crash (much - Flash sometimes does manage to crash it), but that's because extensions are written in Javascript and XML. You can write Plasmoids in Javascript too, and they won't crash.

I dislike C because memory leaks. All know software developed in C has memory leaks that causes crashes. Seem to be obvious that both Plasma and Konqueror 4 has more memory leaks than the standard C program.
But you write something interesting, if Javascript plasmoids was more stable, why all plasmoids are not written in Javascript? It's the perfect solution, a solid base writen in C++ and plasmoids writen in javascript with Qtscript acts like a protection shield to plasma. The only explanation I found is that develop using C++ is cool and develop with Javascript is uncool.

Alec wrote:Because software is not magic. If you knew how to program, you'd understand the complexity involved in masking a project both fast, flexible and reliable, especially if it is a large project.

I know it and thats the reason why we, in my company, the most important goals was build software reliable and flexible and, when we achieve this goal, we begin to profile the code and optimize it to be fast and use test cases to check the optimizations. If you design your code thinking only in that work fast, you finish with a high unstable piece of ****, even bigger than flash player.

If we sell software as unstable, I think that is important to remark that both Konqueror and Plasma was in 4.3.2 version and was consider stable software, we are out of the market.

> I dislike C because memory leaks. All know software developed in C has
> memory leaks that causes crashes. Seem to be obvious that both Plasma
> and Konqueror 4 has more memory leaks than the standard C program.

It's not the language that introduces memory leaks, it's the programmer. You got memory leaks in any compiled language.

samhain wrote:> I dislike C because memory leaks. All know software developed in C has
> memory leaks that causes crashes. Seem to be obvious that both Plasma
> and Konqueror 4 has more memory leaks than the standard C program.

It's not the language that introduces memory leaks, it's the programmer. You got memory leaks in any compiled language.

Well yes, but for It's nature, is more easy have memory leaks in C than, for example, in Pascal. In a Valgrind presentation in my city doing for Albert Astald Cid, a KDE developer, there is one sample where thing seems to be well coded but there is a memory leak detected by Valgrind, sorry I don't remember the example, but was related to a value returned by a function, and when he explain the problem I don't believe that a C programmer must fight with this kind of stuff in his daily basics.

Sorry, I have better things to do in my work than spend my time thinking as a compiler neither a cpu and test all my code with Valgrind, because there is a memory leak or a bug that I can't see with my eyes. I prefer spend my time writing test cases and documenting my code.

I think that C/C++ was a good language but not a general purpose language. For example, Plasmoids was a stuff that should be coded using a high level language and Plasma is a big candidate to C/C++.

If is it not perfectly clear, this was a personal opinion and I don't try to convince anybody to use one language or other .

RGB wrote:Well, to be fair not only kde is following the "one process" road

KDE is not at all followinf the "one process" road.
In fact a lot of KDE infrastructure is based on service processes (service oriented architecture if you like buzz words), e.g. KIO slaves, klauncher, kded, etc.

If something is implemented within the same process it is usually because there is a technical limitation making out-of-process a worse choice or there is some kinf od heavy gain of having things in-process.

Cheers,
_

Ignacio Serantes wrote:With konqueror, when flas player crash konqueror goes to hell but, with Chrome, not only chrome survives, the page survives too and only the flash container is broken.

Flash, or actually any "Netscape Plugin" is running in its own process, nspluginviewer. This has always been part of the Konqueror (or more specifically KHTML) achrictecture.

Similar approach for Java. Where other browser would block on loading a Java applet, Konqueror would still be responsive since it started Java as a separate process (in this case the real java VM, not some sort of plugin)

Cheers,
_

One-process-multi-threads comes from Windows, where creating processes and context swiches are very expensive. On Unix-like OS that was never an issue.

An other point is that interprocess communication needs some more thinking than threads.

anda_skoa wrote:

RGB wrote:Well, to be fair not only kde is following the "one process" road

KDE is not at all followinf the "one process" road.
In fact a lot of KDE infrastructure is based on service processes (service oriented architecture if you like buzz words), e.g. KIO slaves, klauncher, kded, etc.

If something is implemented within the same process it is usually because there is a technical limitation making out-of-process a worse choice or there is some kinf od heavy gain of having things in-process.

Cheers,
_

Of course you are right. I was not thinking on the whole kde but on plasma when I wrote that sentence, but typed kde... Thanks for correcting me.

Alec wrote:it's not really Konqueror's fault that Flash is a piece of shіt.

Thank you. Just... thank you.