Development :
K-Meleon Web Browser Forum
I saw a posting on the mailing list regarding a K-Meleon roadmap, a few comments:
How about a roadmap based on K-Meleon bugs and RFEs which will be addressed for each release through 1.0 ? Do you have such a list and if so could you post it for the curious ?
Having a release coincide with a Mozilla build would be nice except that Mozilla is never on schedule. It's good to see that Mozilla 1.3 will be skipped but I've read that many changes will be done on Gecko for 1.4 to hopefully improve performance. This of course could introduce new problems. Is there any chance that K-Meleon 0.8 could be based on Mozilla 1.2.1 ?
Updated plugins should be released more often.
About your proposed updated preference panels:
Clear URL bar and history buttons would certainly be welcomed.
Ability to select the download directory should be on the new advanced panel. Note there are currently two prefs "browser.download.dir" and "kmeleon.general.saveDir" only one, probably the first should be used.
Consider adding Cookies to the Configs panel.
Languages panel doesn't seem important at all.
As for about:config, isn't that a xul thing requring Mozilla DLLs that handle xul ? I suppose you could make the prefs display work using Javascript document.write to create a table but not the editing. K-Meleon should use less xul (preferably none) not more.
> Clear URL bar and history buttons would certainly be welcomed.
yep. but *please* put them to the "cache" panel, so that the field for entering the no-pop-up-domains is *not* so extremly *small*!
yeah, and add an option for the cookie warning.
asmpgmr,
Thanks for the feedback. Comments included below:
"How about a roadmap based on K-Meleon bugs and RFEs which will be addressed for each release through 1.0 ? Do you have such a list and if so could you post it for the curious?"
We have a features-based document for 0.8 in draft form. It is currently being reviewed by the developers. Once I have their feedback, I'll post that for general viewing and comments. It generally doesn't focus on specific bugs as we hope that most of them will be addressed as features are implemented or improved. Of course, bug squashing is part of the work list for 0.8 and all releases. We also have a preliminary 1.0 features list that is in the development and review process. Watch for more news about that soon.
"Having a release coincide with a Mozilla build would be nice except that Mozilla is never on schedule. It's good to see that Mozilla 1.3 will be skipped but I've read that many changes will be done on Gecko for 1.4 to hopefully improve performance. This of course could introduce new problems. Is there any chance that K-Meleon 0.8 could be based on Mozilla 1.2.1 ?"
The plan is still to release 0.8 on whatever the most current stable Mozilla code is available at the time of release. We have quite a long to-do list for 0.8 so we are still looking at several months, at the earliest, before we release it. That's why I would expect it will be built on Mozilla 1.4 code. As far as the 1.3 code, I just built K-Meleon this morning using the latest nightly 1.3 code and it runs fine. In my little bit of testing, I didn't see any significant Mozilla bugs that affected K-Meleon.
"Updated plugins should be released more often."
We have been discussing that. Part of the problem is setting up a system for posting updates and getting feedback on changes. Ulf was doing that but didn't feel like he was getting enough feedback from users to justify the work.
"About your proposed updated preference panels:
...
Ability to select the download directory should be on the new advanced panel. Note there are currently two prefs "browser.download.dir" and "kmeleon.general.saveDir" only one, probably the first should be used."
Yes, I made note of that at the very end of the document. I would look at including that in the Advanced panel if we go that route.
"Consider adding Cookies to the Configs panel."
Good suggestion. On the feature release list is a request for a Cookie Manager. That might make a good interim step to that.
"Languages panel doesn't seem important at all."
This has been a huge issue with adoption of K-Meleon by non-native English speakers. Internationalization is a big focus for 0.8 and 1.0.
"As for about:config, isn't that a xul thing requring Mozilla DLLs that handle xul ? I suppose you could make the prefs display work using Javascript document.write to create a table but not the editing. K-Meleon should use less xul (preferably none) not more."
Yes, it is XUL-based. Our goal is to have less, not more, XUL. However, this is also an important feature for end-users. If someone can code up a non-XUL version, it would be much appreciated.
Ra,
"yep. but *please* put them to the "cache" panel, so that the field for entering the no-pop-up-domains is *not* so extremly *small*!"
We'll work on the layout issues. I realize that the version I posted was pretty limited. I expect as we re-arrange items, this problem will be addressed.
thx.
Andrew,
My problem with Mozilla 1.3 is that they posted they have a hang bug on win9x (I use win98se) instead of fixing it before releasing 1.3b. It's irresponsible to release software, even beta software with known hang or crash bugs which occur regularly. Now if the bug is in their bloated UI code then it doesn't matter to K-Meleon but if it's in Gecko or the networking code then it does.
Couldn't updated plugins be put on the download page ? I would try the latest bookmarks and macros plugins if they were posted as long as they weren't debug builds.
As for about:config editing, in the end isn't this just a non-essential cutesy thing ? How is it really better than going to the prefs config panel or using a text editor to edit prefs.js ? I think having a cookie manager plugin is more useful and desired than somewhat redundant about:config editing.
Please describe what the purpose of URL bar plugin is. I read on one of the forums that it would completely replace the existing the URL bar and basically be a required plugin which doesn't sound good. I also read that there would be some issues with such a plugin as opposed to the existing "native" URL bar. I think the URL bar and any related functionality like URL autocompletion should be part of the main program since the URL bar is a basic element of a browser.
asmpgmr,
"My problem with Mozilla 1.3 is that they posted they have a hang bug on win9x (I use win98se) instead of fixing it before releasing 1.3b. It's irresponsible to release software, even beta software with known hang or crash bugs which occur regularly. Now if the bug is in their bloated UI code then it doesn't matter to K-Meleon but if it's in Gecko or the networking code then it does."
Yes, we're aware of the Win9x problems with 1.3. If we build anything on 1.3, it will only be on the final source code. Also, it's likely to only be a beta release. We won't release a final release that doesn't work on Win9x systems.
"Couldn't updated plugins be put on the download page? I would try the latest bookmarks and macros plugins if they were posted as long as they weren't debug builds."
We could and we might. But someone has to be responsible for building them and keeping track of the feedback. I'll post more info. once we resolve that issue.
"As for about:config editing, in the end isn't this just a non-essential cutesy thing ? How is it really better than going to the prefs config panel or using a text editor to edit prefs.js ? I think having a cookie manager plugin is more useful and desired than somewhat redundant about:config editing."
True, users can still edit prefs.js. But this provides a more handy graphical editor that lets us consolidate all prefs in one location. It would also allow us to simplify our preference panels by removing some of the more obscure or less used preferences. Again, we haven't made any final decisions on that. It's just something that we are discussing.
"Please describe what the purpose of URL bar plugin is. I read on one of the forums that it would completely replace the existing the URL bar and basically be a required plugin which doesn't sound good. I also read that there would be some issues with such a plugin as opposed to the existing "native" URL bar. I think the URL bar and any related functionality like URL autocompletion should be part of the main program since the URL bar is a basic element of a browser."
I can't speak to all of the details but as I understand it, the URL bar plugin will give us the ability to incorporate some functionality that hasn't been built into the native URL bar. I'll touch base with the developers for a more detailed explanation on that.
K-Meleon development related discussions.
K-Meleon roadmap (Andrew please read)
Posted by:
asmpgmr
Date: February 23, 2003 03:56PM
I saw a posting on the mailing list regarding a K-Meleon roadmap, a few comments:
How about a roadmap based on K-Meleon bugs and RFEs which will be addressed for each release through 1.0 ? Do you have such a list and if so could you post it for the curious ?
Having a release coincide with a Mozilla build would be nice except that Mozilla is never on schedule. It's good to see that Mozilla 1.3 will be skipped but I've read that many changes will be done on Gecko for 1.4 to hopefully improve performance. This of course could introduce new problems. Is there any chance that K-Meleon 0.8 could be based on Mozilla 1.2.1 ?
Updated plugins should be released more often.
About your proposed updated preference panels:
Clear URL bar and history buttons would certainly be welcomed.
Ability to select the download directory should be on the new advanced panel. Note there are currently two prefs "browser.download.dir" and "kmeleon.general.saveDir" only one, probably the first should be used.
Consider adding Cookies to the Configs panel.
Languages panel doesn't seem important at all.
As for about:config, isn't that a xul thing requring Mozilla DLLs that handle xul ? I suppose you could make the prefs display work using Javascript document.write to create a table but not the editing. K-Meleon should use less xul (preferably none) not more.
Re: K-Meleon roadmap (Andrew please read)
Posted by:
ra
Date: February 23, 2003 05:24PM
> Clear URL bar and history buttons would certainly be welcomed.
yep. but *please* put them to the "cache" panel, so that the field for entering the no-pop-up-domains is *not* so extremly *small*!
yeah, and add an option for the cookie warning.
Re: K-Meleon roadmap (Andrew please read)
Posted by:
Andrew
Date: February 23, 2003 08:43PM
asmpgmr,
Thanks for the feedback. Comments included below:
"How about a roadmap based on K-Meleon bugs and RFEs which will be addressed for each release through 1.0 ? Do you have such a list and if so could you post it for the curious?"
We have a features-based document for 0.8 in draft form. It is currently being reviewed by the developers. Once I have their feedback, I'll post that for general viewing and comments. It generally doesn't focus on specific bugs as we hope that most of them will be addressed as features are implemented or improved. Of course, bug squashing is part of the work list for 0.8 and all releases. We also have a preliminary 1.0 features list that is in the development and review process. Watch for more news about that soon.
"Having a release coincide with a Mozilla build would be nice except that Mozilla is never on schedule. It's good to see that Mozilla 1.3 will be skipped but I've read that many changes will be done on Gecko for 1.4 to hopefully improve performance. This of course could introduce new problems. Is there any chance that K-Meleon 0.8 could be based on Mozilla 1.2.1 ?"
The plan is still to release 0.8 on whatever the most current stable Mozilla code is available at the time of release. We have quite a long to-do list for 0.8 so we are still looking at several months, at the earliest, before we release it. That's why I would expect it will be built on Mozilla 1.4 code. As far as the 1.3 code, I just built K-Meleon this morning using the latest nightly 1.3 code and it runs fine. In my little bit of testing, I didn't see any significant Mozilla bugs that affected K-Meleon.
"Updated plugins should be released more often."
We have been discussing that. Part of the problem is setting up a system for posting updates and getting feedback on changes. Ulf was doing that but didn't feel like he was getting enough feedback from users to justify the work.
"About your proposed updated preference panels:
...
Ability to select the download directory should be on the new advanced panel. Note there are currently two prefs "browser.download.dir" and "kmeleon.general.saveDir" only one, probably the first should be used."
Yes, I made note of that at the very end of the document. I would look at including that in the Advanced panel if we go that route.
"Consider adding Cookies to the Configs panel."
Good suggestion. On the feature release list is a request for a Cookie Manager. That might make a good interim step to that.
"Languages panel doesn't seem important at all."
This has been a huge issue with adoption of K-Meleon by non-native English speakers. Internationalization is a big focus for 0.8 and 1.0.
"As for about:config, isn't that a xul thing requring Mozilla DLLs that handle xul ? I suppose you could make the prefs display work using Javascript document.write to create a table but not the editing. K-Meleon should use less xul (preferably none) not more."
Yes, it is XUL-based. Our goal is to have less, not more, XUL. However, this is also an important feature for end-users. If someone can code up a non-XUL version, it would be much appreciated.
Re: K-Meleon roadmap (Andrew please read)
Posted by:
Andrew
Date: February 23, 2003 08:45PM
Ra,
"yep. but *please* put them to the "cache" panel, so that the field for entering the no-pop-up-domains is *not* so extremly *small*!"
We'll work on the layout issues. I realize that the version I posted was pretty limited. I expect as we re-arrange items, this problem will be addressed.
Re: K-Meleon roadmap (Andrew please read)
Posted by:
ra
Date: February 23, 2003 09:34PM
thx.
Re: K-Meleon roadmap (Andrew please read)
Posted by:
asmpgmr
Date: February 23, 2003 09:35PM
Andrew,
My problem with Mozilla 1.3 is that they posted they have a hang bug on win9x (I use win98se) instead of fixing it before releasing 1.3b. It's irresponsible to release software, even beta software with known hang or crash bugs which occur regularly. Now if the bug is in their bloated UI code then it doesn't matter to K-Meleon but if it's in Gecko or the networking code then it does.
Couldn't updated plugins be put on the download page ? I would try the latest bookmarks and macros plugins if they were posted as long as they weren't debug builds.
As for about:config editing, in the end isn't this just a non-essential cutesy thing ? How is it really better than going to the prefs config panel or using a text editor to edit prefs.js ? I think having a cookie manager plugin is more useful and desired than somewhat redundant about:config editing.
Please describe what the purpose of URL bar plugin is. I read on one of the forums that it would completely replace the existing the URL bar and basically be a required plugin which doesn't sound good. I also read that there would be some issues with such a plugin as opposed to the existing "native" URL bar. I think the URL bar and any related functionality like URL autocompletion should be part of the main program since the URL bar is a basic element of a browser.
Re: K-Meleon roadmap (Andrew please read)
Posted by:
Andrew
Date: February 24, 2003 03:30AM
asmpgmr,
"My problem with Mozilla 1.3 is that they posted they have a hang bug on win9x (I use win98se) instead of fixing it before releasing 1.3b. It's irresponsible to release software, even beta software with known hang or crash bugs which occur regularly. Now if the bug is in their bloated UI code then it doesn't matter to K-Meleon but if it's in Gecko or the networking code then it does."
Yes, we're aware of the Win9x problems with 1.3. If we build anything on 1.3, it will only be on the final source code. Also, it's likely to only be a beta release. We won't release a final release that doesn't work on Win9x systems.
"Couldn't updated plugins be put on the download page? I would try the latest bookmarks and macros plugins if they were posted as long as they weren't debug builds."
We could and we might. But someone has to be responsible for building them and keeping track of the feedback. I'll post more info. once we resolve that issue.
"As for about:config editing, in the end isn't this just a non-essential cutesy thing ? How is it really better than going to the prefs config panel or using a text editor to edit prefs.js ? I think having a cookie manager plugin is more useful and desired than somewhat redundant about:config editing."
True, users can still edit prefs.js. But this provides a more handy graphical editor that lets us consolidate all prefs in one location. It would also allow us to simplify our preference panels by removing some of the more obscure or less used preferences. Again, we haven't made any final decisions on that. It's just something that we are discussing.
"Please describe what the purpose of URL bar plugin is. I read on one of the forums that it would completely replace the existing the URL bar and basically be a required plugin which doesn't sound good. I also read that there would be some issues with such a plugin as opposed to the existing "native" URL bar. I think the URL bar and any related functionality like URL autocompletion should be part of the main program since the URL bar is a basic element of a browser."
I can't speak to all of the details but as I understand it, the URL bar plugin will give us the ability to incorporate some functionality that hasn't been built into the native URL bar. I'll touch base with the developers for a more detailed explanation on that.
English