Hi!

With Mozilla 1.8b1 out of the door, it would be great to see an updated K-Meleon build based on that version.

(You) Andrew indicated that Ulf would be willing to put a version based on 1.8x together. Is this still true?

So, how about getting on the road to Mozilla 1.8 in the next few weeks ('days' would just be too fast for K-M, wouldn't it? *g*)? :-)

I tried compiling K-M 0.9 against Mozilla 1.8b1 and it requires some changes in K-M's UnknownContentTypeHandler. So it would be great to see an updated CVS or source package somewhere, too.

TIA!

Ra,

Looks like there will never be a final Mozilla 1.8. This from Asa:

"James, we've committed to maintaining the Mozilla application suite on the 1.7 branch with stability and security fixes for at least another year."

"I don't believe that the Mozilla Foundation has the resources to support an ongoing Seamonkey "product" (beyond our commitment to the 1.7.x releases) but I'll bet (I'm just guessing here) that the cost of supporting a Seamonkey "project" with CVS, FTP, http://www.mozilla.org pages, etc, wouldn't be a problem. We already do this for several projects that we don't actively "productize".

-Asa Dotzler
February 27, 2005

http://weblogs.mozillazine.org/asa/


Nick

@ ndebord that is not too nice -

I also had no luck with ftp_client from other thread.
I tried with my latest w-b chrome.
I will run test with that chrome and mozilla 1.8.6


@ra: i have a w-b chrome that is updated to 1.8.6 & i could try to update 1.8b1
but i (like others) have other work to do as well - so it may take.....

regards to all

ndebord,

I think you misunderstood what Asa said here. There sure will be a Mozilla 1.8, but they are marketing FireFox, no Seamonkey (aka the suit) *product*.

BTW: There's currently one source package and you can compile FireFox or Mozilla or ... from that package, just as you like. We only need Gecko, so even when Mozilla.org wouldn't update Mozilla anymore (the interface already is close to frozen) that wouldn't matter to us.

guenter,

although that would be nice and a quick way to get onto 1.8 it would also be a quick way to run into problems. You're only exchanging files, crossing your fingers that K-M will still work with updated files. ;-) But it doesn't make much sense to do 'real' development work without compiling against the version of the Gecko that the browser will run with later on.

The changes are minimal I think and s.o. who knows C++ or the changes that Mozilla.org did will be able to fix this in a minute or two.

"against the version of the Gecko" should of course have been "against the version of Gecko", no "the" before Gecko, ouch!

Yes it has to be compiled but chrome is always cherry picked ; o )
after that You can test chromes with e. g. browser only install or other k-m that have the same major version. -- 1.8.6 is tested since Dezember without problem.

but mind me i hardly ever run into bugs

Ra,

<<I think you misunderstood what Asa said here. There sure will be a Mozilla 1.8, but they are marketing FireFox, no Seamonkey (aka the suit) *product*.>>

I don't know that I agree with you on this.

As I read what Asa says, there will be NO release of a Mozilla 1.8. He does say as you note that there will be nightlies for updates and the beta, but he distinctly says that the offical releases end with the 17.xxx official release. I read that as maintenance at best. Corporate grumbling is a good indicator to my mind and I see them saying that 1.7xxx is not enough. Comments like the integrated suite is what IT sold corporate boards on and that FF/TB combo is a) not as stable as Seamonkey and b) not similar enough in terms of interface which makes training that much harder.


N

Ra,

<<There's currently one source package and you can compile FireFox or Mozilla or ... from that package, just as you like. We only need Gecko, so even when Mozilla.org wouldn't update Mozilla anymore (the interface already is close to frozen) that wouldn't matter to us.>>

Yes, that is what I thought as far as K-Meleon. I just think they are making a mistake with dumping Seamonkey as a supported platform. I understand the reluctance as they had said from the very first that Seamonkey was a testbed and were surprised by how quickly it became popular. Still, when you look at Netscape and Mozilla, the suite idea has been easy to adopt for many individuals and businesses.

N

Guenter,

<<I also had no luck with ftp_client from other thread.>>

That's too bad. I had hoped that FireFtp would be similar to Aggreg8 for KM, but perhaps there is another solution out there to be found.

<sigh>

N

FireFtp is a waste of time. The idea of integrating an ftp client into firefox is good, but the result is horrendously slow and bloated. It's slow to load, and causes my entire system to slow down while it's running. You're much better off with a seperate ftp prog.

IMO The biggest advantage the suite has over ff/tb is the editor. In fact, I find the editor far more useful than the email client.

Drahken,

I assume you are talking about Composer. I've always been interested in what people say when they compare Composer and Nvu. Both of which I've used, but not extensively.

N

I am using the Moz.Suite on my Linux system for some months now and also make my own Suite builds every day. So you can imagine I was dissapointed and a little angry after reading the thoughts and ideas about the Moz.Suite on the Mozilla forums.
But as said before, it is not true that the Suite development will end. When I read it right they will use the Suite for testing new developments and although not official, they will even go to a 2.0 release. The developments they have tested on the Suite are used then in FF and TB.
I have to say I think this is a little strange, because why using the Suite for testing when you want to use it for FF and TB? But this is how I am reading it.
And I hope it is true, otherwise I will stop using the Suite and switch to Opera, my second browser at the moment ;-)))

Jan.

Fast Sjonny,

Yes, they say development will continue, but as I read the tea leaves, it is apparent to me that what they mean is maintenance work on Mozilla. The Gecko engine itself is something else entirely. New features imo will be a FF only phenomenon. If Mozilla wants to survive as an innovative kitchen suite, it will have to be done outside the Mozilla Foundation as is the case with Galeon, Camino and K-Meleon. I saw that they just grabbed one of the Camino developers to work in the Mozilla Foundation. His job will be to make sure Jaguar, Panther and sonn to come Tiger all work well with FireFox, not Camino!

N

I think he mainly means that they are committed finannicially on 1.7 for so long.
probably they will have keystone releases again - but not with 1.8.

@Jan - can You explain what a *.pl does - i found one that is supposed to join xpt.
do You know to do it? I managed to get my update of chrome finished last night.
I have a working chrome made from 1.8.b1 now - it runs well with browser only install!
In fact on my aged system a browser only mozilla install is as fast as a FF, he he.
especially when i use Your w-b chrome (which i updated).

...

Is anyone in here, who can post what has to be changed to be able to compile K-M against 1.8x?

@ra
sorry i only can update chromes -

did You look into wiki about ist? (AFAIK under k-m development is an english how ro)
Gemal dk bowser spy has something general about compiling with free Gecko sources.

both additionally link to source on mozilla.

p.s .
weiss leider nur wie man chromes updated und macht
- wenn du wenn findest -
den chrome hätten/haben wir dann schon.
er ginge u. U. auch mit haos

Read this: http://www.steelgryphon.com/blog/index.php?p=32

I agree with this.: "When they quit developing the suite I will go to OPERA [8 beta2] or something else."
And 'something else' is K-Meleon, no Fx.

btw. Gecko 1.8 is fastest yeah.

Sorry Guenter, can not help you with that one ;-)))

Nice to hear you are still using bits and pieces of Wechselbalg!
I have removed the downloadcounter, but there are still about 50 downloads a week for our old static K-Meleon Wechselbalg. (a little promotion: http://www.hch.uwnet.nl/k-meleon )

Mlog, thank you for the link!

B.t.w., when I was still using Windows, I had never switched from KM to another browser. But on my Linux-system the Suite is very fast and stable solution.

Last word; the Gecko 1.8 is very fast. It would be nice to make a KM based on the latest 1.8b2, which is very fast and stable.

Jan.

Guessing from the error messages I'm getting (see below) and the list here it looks like it has to do with freezing nsIWebProgress and nsIWebProgressListener (99639) and K-M using these interfaces in its UnknownContentTypeHandler.

If anyone is interested in the error messages (I altered my path and I hope that the forum doesn't make the messages look too ugly):

Compiling...
BrowserViewUtils.cpp
x:\xyz\k-meleon\UnknownContentTypeHandler.h(42) : error C2584: 'CProgressDialog' : direct base 'nsIWebProgressListener' is inaccessible; already a base of 'nsIDownload'
../mozilla/mozilla/dist/include/uriloader\nsIWebProgressListener.h(40) : see declaration of 'nsIWebProgressListener'

MfcEmbed.cpp
x:\xyz\k-meleon\UnknownContentTypeHandler.h(42) : error C2584: 'CProgressDialog' : direct base 'nsIWebProgressListener' is inaccessible; already a base of 'nsIDownload'
../mozilla/mozilla/dist/include/uriloader\nsIWebProgressListener.h(40) : see declaration of 'nsIWebProgressListener'
x:\xyz\k-meleon\MfcEmbed.cpp(167) : error C2653: 'nsComponentManager' : is not a class or namespace name
x:\xyz\k-meleon\MfcEmbed.cpp(167) : error C2065: 'RegisterFactory' : undeclared identifier
x:\xyz\k-meleon\MfcEmbed.cpp(177) : error C2653: 'nsComponentManager' : is not a class or namespace name
x:\xyz\k-meleon\MfcEmbed.cpp(187) : error C2653: 'nsComponentManager' : is not a class or namespace name
x:\xyz\k-meleon\MfcEmbed.cpp(189) : error C2065: 'NS_DOWNLOAD_CONTRACTID' : undeclared identifier
x:\xyz\k-meleon\MfcEmbed.cpp(197) : error C2653: 'nsComponentManager' : is not a class or namespace name

UnknownContentTypeHandler.cpp
x:\xyz\k-meleon\UnknownContentTypeHandler.h(42) : error C2584: 'CProgressDialog' : direct base 'nsIWebProgressListener' is inaccessible; already a base of 'nsIDownload'
../mozilla/mozilla/dist/include/uriloader\nsIWebProgressListener.h(40) : see declaration of 'nsIWebProgressListener'
x:\xyz\k-meleon\UnknownContentTypeHandler.cpp(737) : error C2039: 'SetDisplayName' : is not a member of 'CProgressDialog'
x:\xyz\k-meleon\UnknownContentTypeHandler.h(37) : see declaration of 'CProgressDialog'
Generating Code...
Error executing cl.exe.

k-meleon.exe - 10 error(s), 0 warning(s)

Okay, can't be nsIWebProgress or nsIWebProgressListener. quote:

Darin Fisher Oct 31 2004, 9:08 am
Newsgroups: netscape.public.mozilla.embedding

nsIWebProgress and nsIWebProgressListener are now frozen

See https://bugzilla.mozilla.org/show_bug.cgi?id=99639 for details.

These interfaces remain unchanged since Mozilla 1.1. They will be
included with the Gecko SDK starting with Mozilla 1.8.

Looks like the nsIDownload API change is more likely to be the one that's causing trouble. quote:

Christian Biesinger Jan 6, 7:22 am
Newsgroups: netscape.public.mozilla.embedding

In Mozilla 1.8a6, the nsITransfer and nsIDownload interfaces got changed
in an incompatible way. The new interfaces can be seen at:

http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsITransfer.idl
http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsIDownload.idl

Note that, as an embeddor, you need not implement nsIDownload anymore,
and it will become a frontend-specific API soon.

nsITransfer now inherits from nsIWebProgressListener, so there is no
need to inherit from the latter explicitly.

The Contract ID ("@mozilla.org/download;1") for download objects was not
modified.

See https://bugzilla.mozilla.org/show_bug.cgi?id=241082 for the bug
where this happened.

nsITransfer is expected to be frozen soon, probably for 1.8beta.

Mmh...

Jan,
Do you think we need to do an upgrade of our Wechselbalg of latest KM source and mozilla 1.8 b1?


Hao

Hi Hao,

It would be nice to have a static 0.9 build and it would be even better if it was based on the latest Gecko. I think this build would be about 20 percent faster then the latest 0.9 with the same functionality. But that is just guessing ofcourse ;-))))
The problem is; who is willing to make the build????
- menu's, macro's etc... must be updated (translations of the latest 0.9 menu's)
- someone must build it
- the chrome must be cleaned (based on the latest 1.8b2)
- etc....

Jan

the 1.8. branch has become really fast with the 1.8.b1 - i like its speed.
Jan have a look at mail @ wb-lontronics - hao @ gmail account. regrads

you both have mail ;-)))

Jan

ra:
The same building problem here. Is there anyway to solve this problem and build KM?

Hao

Is there anyway to solve this problem and build KM?

There sure is a way.

We only have to slightly change K-M's code because of code changes in Mozilla (like it happened regularly in the past ;-) ).

Sadly I don't have the time to have a longer look at it (and it takes time for me, not being a C-coder and knowing not enough about that part of the code). But if you know what to change I'm interested in the necessary changes.

I still hope that Andrew might join this thread and give some insight whether there's hope for a 1.8.x-based version (and source!) or not..