K-Meleon :: General

General : K-Meleon Forum

General discussion about K-Meleon.

Goto: Forum List•Message List•Search•Log In

Your Name:
Subject:

Help information

[quote=rodocop]
The main problem remains the lack of coders.

But KM can really go on: in the [url=http://kmeleon.sourceforge.net/forum/read.php?2,118473]parallel thread[/url] there are very useful link where we can find things that reassure:
[quote=butlerm]
If you read the original post, what is really being killed isn't embedding support per se, but rather in process embedding support. Out of process embedding support may be added in the future. That seems like the right way to do it to me.

[color=#990000][b]So presumably all of these alternative browsers could, in the future, host a Gecko process that actually does html rendering and javascript execution, without adopting the user interface[/b][/color] aspects of Firefox at all.
[/quote]

[quote=kripkenstein]
[u]I'm a developer at Mozilla.[/u] It looks like there is some confusion about this announcement.

1. Most importantly, [b][color=#990000]*it is still possible to create applications that use Gecko*[/color][/b]. Even without the Gecko embedding APIs, you can write such apps. For example, there are two separate Mozilla-supported apps that use Gecko: Firefox and Fennec (mobile Firefox). There is also Songbird, which is written in a similar way (the article mistakenly implies Songbird will be negatively affected by this announcement, which is not true - the situation for them is very different than for Camino, for example).

In other words, you *can* still write Gecko apps, but you must integrate tightly with Gecko. This is sort of like the Linux kernel not committing to a stable API, things change as needed (people sometimes complain about that, but overall it lets the kernel move forward faster). Similarly, for Mozilla moving forward is much easier without committing to stable APIs for embedding. But again, you can still write apps that use Gecko without such APIs, just like you can write code for Linux.

2. Second, to clarify the term 'killed' that the article used: [b][color=#990000]If someone steps up to maintain the embedding APIs, they can continue.[/color][/b] So in that sense [u]nothing is 'killed'[/u]. [i]It is just that Mozilla itself, however, isn't focusing on them,[/i] for the reasons I mentioned before.

So, where does this leave things? If you want to write an app that embeds an HTML engine, you can still choose Gecko or WebKit. WebKit is easier to embed, but that has a price. As an example, look how quickly Google added cross-process support to Chrome, without any stable API promises and without anything but Chrome benefiting; Apple is adding cross-process support to WebKit itself, with a stable API, but it is still not complete as the process takes much longer.

I would argue, however, and this is totally my personal opinion - not Mozilla's - that all of this *doesn't really matter*. The places that need to embed a web browser are decreasing, not increasing, because things are moving *into* web browsers, not vice versa. What I am trying to say, is that these days people fire up their web browser and do everything from read news to check email to play games. They don't have separate apps for each that embed a web browser, they have a single web browser for all their activities.

Current applications that embed web browsers, like say Songbird, could today be websites or browser plugins, as browser capabilities have improved so much recently. For that matter, alternative browsers like Flock and RockMelt could be browser plugins.

[color=#990000]That leaves projects like Camino and Epiphany that provide much better OS integration than cross-platform browsers like Firefox or Chrome. There is a place for such OS integration.[/color] Some of it can be achieved with browser plugins, but I concede that it might be necessary in some cases to do more. I think that such work code be done with the upstream projects, though, to get the best results, as opposed to separate projects that just embed rendering engines. For example, Firefox can render using Qt on Linux, but it needs more love - would be great to see more Qt hackers contribute upstream on that, and to get Firefox/Qt stable.
[/quote]

This shows that it is real to separate rendering engine from GUI and freely combine them on demand. This gives KM good chance not only for survival as Windows native Gecko tool but for expansion to the other platforms, including Linux, Mac and even mobile devices...

So, we just need a team of few competent coders - and there are no overwhelming restrictions they can be faced to...
The main question is - WHERE to find this team and HOW to interest these coders in working on KM development.

Now I'm trying to provide conditions for this team appearance. It's not easy and there are no guarantee this project would be successful, but it worth try to...

I live in Saint-Petersburg, one of the world leading places in software programming (you could know SPb Mobile Shell for WinMobile by SPb Software House, for example, and this is very little bit of SPb coding community).

So I hope to find like-minded persons here to give K-Meleon a chance...

But all worldwide volunteers are highly welcome![/quote]

K-Meleon forum is powered by Phorum.