Development :
K-Meleon Forum
Well eventually there will be a windows port of Khtml since the KDE devs seem to think people would actually care about a shell that presents almosy nothing different from the IE shell. So in the not too distant future it should be more feasible to have a windows based browser utilize the Khtml engine.
It looks like bloat is becoming a popular excuse to propose starting over. Firefox originated because some developers thought Mozilla was bloated.
Gecko is cross-platform, and that's why it needs to load longer than your standard crappy browser (you know which one), which in turn makes people think it's bloated. When it comes to rendering, though, it's very fast. This has been proved enough. K-Meleon removes the cross-platform bit, and uses Windows APIs instead. So it's fast both in loading and rendering.
Gecko browsers (other than KM) are bloated. They are slow to load, and they have a large memory footprint. That is called bloat. A prog can be bloated and yet still perform a task fast. owever, this bloat is a result of the GUI, not the rendering engine. Changing to KHTML might make KM even faster than it already is (I don't know, since I don't have access to anything that uses KHTML to test with), but the gecko GRE isn't bloated to begin with.
I for one would like to see KHTML brought to windows so that we have more options (choice is always a good thing), and see KM as the most likely vehicle for it. However, I would like to see it as an optional deal (have 2 versions of KM available, or have it capable of using either engine).
You forget that they are cross-platform, which means their interface is made entirely of XUL instead of native APIs. That's slower than applications integrated with the OS by default, and does not indicate bloat.
As for taking up much memory, that's a popular complaint made by people who don't understand that pages these days get large, and that there is such a thing as memory cache. Also, since XUL is used instead of APIs that are already loaded, that takes more memory, and does not indicate a memory hog.
There was an old Mozilla bug that gobled up memory. AFAIK that bug is solved by now.
Some ppl seem to rechew that or think of it.
And memory managment of some older win32 (such as the win ME i used)
was not very good. Some ppl seem to credit the browser with the fault caused of big html pages
with active content and bad windows memory managment.
Memory bloat is comparing recent versions of firefox and seamonkey with similar versions of k-meleon, on an XP system. FF and SM soak up considerably more resources than KM while displaying the same page. Since the 2 progs use more memory that KM, without actually doing anything more, they are bloated. Period. I realize that XUL is the source of most (if not all) of this bloat (hell, XUL=bloat), but I also know that XUL is inherant to FF/SM/etc. If you removed the XUL, you would have nothing but the rendering engine. Now, since XUL=bloat and since FF/SM=XUL, FF/SM=bloat.
Bloat is not measured just by size, rather by how much of that size is not useful (and using XUL is useful because it reduces coding time and effort). See also this argument.
Bloat is something that prvoides no useful function to the USER. XUL provides no useful function to the user (that couldn't be achieved without all that bloat by using some other coding).
XUL is IMHO usefull for coding some things like settings windows and listings
(e.g.in kmprefs.jar or the new javaconsole )
but FFox and SM are often using it for things that can be done without extra RAM & parsing time with native widgets & kplugins or macros like k-m. Its not exactly bloat as BenoitRen pointed out but inefficiant when You do not need it to be cross platform.
btw. I think their licence blocks in every file is bloat that at least slows startup if not more.
I think they posted a wrong archive, It says 0.1.100 inside, i know it since X/06.
I wonder whether Swift could be a GRE for shells or better a browser that we can start by macro like IE or Opera & Fox (lately created by alain for oncoming 1.1).
Edited 1 time(s). Last edit at 11/29/2006 12:30PM by guenter.
K-Meleon development related discussions.
Re: why not use khtml?
Posted by:
Shadow Skill
Date: July 28, 2006 07:08PM
Well eventually there will be a windows port of Khtml since the KDE devs seem to think people would actually care about a shell that presents almosy nothing different from the IE shell. So in the not too distant future it should be more feasible to have a windows based browser utilize the Khtml engine.
Re: why not use khtml?
Posted by:
Jim
Date: August 07, 2006 03:13PM
Re: why not use khtml?
Posted by:
BenoitRen
Date: August 15, 2006 04:57AM
It looks like bloat is becoming a popular excuse to propose starting over. Firefox originated because some developers thought Mozilla was bloated.
Gecko is cross-platform, and that's why it needs to load longer than your standard crappy browser (you know which one), which in turn makes people think it's bloated. When it comes to rendering, though, it's very fast. This has been proved enough. K-Meleon removes the cross-platform bit, and uses Windows APIs instead. So it's fast both in loading and rendering.
Re: why not use khtml?
Posted by:
Drahken
Date: August 25, 2006 09:36PM
Gecko browsers (other than KM) are bloated. They are slow to load, and they have a large memory footprint. That is called bloat. A prog can be bloated and yet still perform a task fast. owever, this bloat is a result of the GUI, not the rendering engine. Changing to KHTML might make KM even faster than it already is (I don't know, since I don't have access to anything that uses KHTML to test with), but the gecko GRE isn't bloated to begin with.
I for one would like to see KHTML brought to windows so that we have more options (choice is always a good thing), and see KM as the most likely vehicle for it. However, I would like to see it as an optional deal (have 2 versions of KM available, or have it capable of using either engine).
Re: why not use khtml?
Posted by:
BenoitRen
Date: August 25, 2006 09:52PM
You forget that they are cross-platform, which means their interface is made entirely of XUL instead of native APIs. That's slower than applications integrated with the OS by default, and does not indicate bloat.
As for taking up much memory, that's a popular complaint made by people who don't understand that pages these days get large, and that there is such a thing as memory cache. Also, since XUL is used instead of APIs that are already loaded, that takes more memory, and does not indicate a memory hog.
Re: why not use khtml?
Posted by:
guenter
Date: August 26, 2006 12:30AM
There was an old Mozilla bug that gobled up memory. AFAIK that bug is solved by now.
Some ppl seem to rechew that or think of it.
And memory managment of some older win32 (such as the win ME i used)
was not very good. Some ppl seem to credit the browser with the fault caused of big html pages
with active content and bad windows memory managment.
Re: why not use khtml?
Posted by:
Drahken
Date: August 28, 2006 11:07PM
Memory bloat is comparing recent versions of firefox and seamonkey with similar versions of k-meleon, on an XP system. FF and SM soak up considerably more resources than KM while displaying the same page. Since the 2 progs use more memory that KM, without actually doing anything more, they are bloated. Period. I realize that XUL is the source of most (if not all) of this bloat (hell, XUL=bloat), but I also know that XUL is inherant to FF/SM/etc. If you removed the XUL, you would have nothing but the rendering engine. Now, since XUL=bloat and since FF/SM=XUL, FF/SM=bloat.
Re: why not use khtml?
Posted by:
rmn
Date: August 29, 2006 04:51PM
Bloat is not measured just by size, rather by how much of that size is not useful (and using XUL is useful because it reduces coding time and effort). See also this argument.
Re: why not use khtml?
Posted by:
rmn
Date: August 29, 2006 04:52PM
Re: why not use khtml?
Posted by:
Drahken
Date: September 06, 2006 02:30AM
Bloat is something that prvoides no useful function to the USER. XUL provides no useful function to the user (that couldn't be achieved without all that bloat by using some other coding).
Re: why not use khtml?
Posted by:
guenter
Date: September 06, 2006 12:14PM
XUL is IMHO usefull for coding some things like settings windows and listings
(e.g.in kmprefs.jar or the new javaconsole )
but FFox and SM are often using it for things that can be done without extra RAM & parsing time with native widgets & kplugins or macros like k-m. Its not exactly bloat as BenoitRen pointed out but inefficiant when You do not need it to be cross platform.
btw. I think their licence blocks in every file is bloat that at least slows startup if not more.
Re: why not use khtml?
Posted by:
guenter
Date: November 29, 2006 12:12PM
I think they posted a wrong archive, It says 0.1.100 inside, i know it since X/06.
I wonder whether Swift could be a GRE for shells or better a browser that we can start by macro like IE or Opera & Fox (lately created by alain for oncoming 1.1).
Edited 1 time(s). Last edit at 11/29/2006 12:30PM by guenter.
