Thanks for pointing me out to this GRE update, guenter I'm happy now with beta 3 and GRE 1.9.1.20pre.

Two posts now imply that there is a 1.6 beta 3 which can be misleading for readers. Unless I'm out of the loop, as of this writing, there is no beta 3. Beta implies that an official build is available for testing and for reporting bugs. There is a beta 2 for that purpose. Any other variants w/updated gecko etc... can only be considered customized experiments at this point. Just wanted to make sure that people don't think they are missing out on an official beta 3 release hidden somewhere.

Quote
jsnj
Two posts now imply that there is a 1.6 beta 3 which can be misleading for readers. Unless I'm out of the loop, as of this writing, there is no beta 3. Beta implies that an official build is available for testing and for reporting bugs. There is a beta 2 for that purpose. Any other variants w/updated gecko etc... can only be considered customized experiments at this point. Just wanted to make sure that people don't think they are missing out on an official beta 3 release hidden somewhere.

thanks for pointing that out, jsnj. km4ever & others should not be mentioning about KM 1.6 beta 3 until that one gets officially released to the general public.

Quote
4td8s
km4ever & others should not be mentioning about KM 1.6 beta 3 until that one gets officially released to the general public.

There's nothing wrong with mentioning test builds in this thread. It's good to hear about core development from deadlock and others, but referring to the personally compiled builds as "beta 3" is both premature and potentially confusing.

Been going here, back and forth to try new builds or beta's before they are officially released. Just the same they are quicker than the other,maybe buggy but I just need a new toy to play with. I have 3 k-mel all sharing the same cache folder................................

I'd really be glad about a soon new 'official beta'. In the last half year there were many little updates, but shattered across the forum, so not really available for new users.
In the meantime I'd be happy with any updated user version, which at least we here in the forum could recommend to others!

It's true that user versions shouldn't use an official name like "beta3", since that one will be published later and be different, so that would only cause confusion and misunderstandings, two versions with the same name

A suggestion for the next beta of 1.6: Please include also a user agent for FF4! I know that's ahead of the KM1.6 gecko version, but meanwhile KM is so far behind that stupid google services (like 'connected accounts') insist that even KM1.6+FF3.5 were "not a supported browser anymore"! Haven't tried yet with a fake FF3.6, but knowing them, they'll block that one soon too ¬_¬ With a FF4 agent though, they suddenly support us again
Even if not all functions may then work correctly, but still a lot better then getting NO functions, and most people have no clue how to add own new custom agents.

Quote
siria
I'd really be glad about a soon new 'official beta'. In the last half year there were many little updates, but shattered across the forum, so not really available for new users.
In the meantime I'd be happy with any updated user version, which at least we here in the forum could recommend to others!

It's true that user versions shouldn't use an official name like "beta3", since that one will be published later and be different, so that would only cause confusion and misunderstandings, two versions with the same name

A suggestion for the next beta of 1.6: Please include also a user agent for FF4! I know that's ahead of the KM1.6 gecko version, but meanwhile KM is so far behind that stupid google services (like 'connected accounts') insist that even KM1.6+FF3.5 were "not a supported browser anymore"! Haven't tried yet with a fake FF3.6, but knowing them, they'll block that one soon too ¬_¬ With a FF4 agent though, they suddenly support us again
Even if not all functions may then work correctly, but still a lot better then getting NO functions, and most people have no clue how to add own new custom agents.

Siria,

Exactly... we need a unified beta3... I would call my current 1.6b2 a hybrid browser as I have so many little changes and modified GRE too.... no longer qualifies as the regular version. And a FF4 user agent string under Tools/User Agent would be very useful. I too have some regularly used websites that won't work with default KM 1.6b2 user agent strings and I have to (sometimes) right click and open up in FF6. Plus using the custom user agent string is just a temporary solution.

N



Edited 1 time(s). Last edit at 08/20/2011 01:44PM by ndebord.

Quote
siria
It's true that user versions shouldn't use an official name like "beta3", since that one will be published later and be different, so that would only cause confusion and misunderstandings, two versions with the same name

I fear nobody but deadlock is working on a new K-Meleon 1.6 beta currently.

So what he has coded so far will IMHO likely be merged into a official beta3 - if there ever is one.

So it would be best if ppl commented on what deadlock asked.



Edited 1 time(s). Last edit at 08/20/2011 03:02PM by guenter.

Quote
guenter

Quote
siria
It's true that user versions shouldn't use an official name like "beta3", since that one will be published later and be different, so that would only cause confusion and misunderstandings, two versions with the same name

I fear nobody but deadlock is working on a new K-Meleon 1.6 beta currently.

So what he has coded so far will IMHO likely be merged into a official beta3 - if there ever is one.

So it would be best if ppl commented on what deadlock asked.

Guenter,

As Deadlock is working on beta3, perhaps we should setup a sticky separate from the current one for him and consolidate his requests and our responses. What do you think?

N



Edited 1 time(s). Last edit at 08/20/2011 05:46PM by ndebord.

Quote
ndebord
As Deadlock is working on beta3, perhaps we should setup a sticky separate from the current one for him and consolidate his requests and our responses. What do you think?

He would have set it up alone - if he wanted it that way.

Quote
guenter

Quote
ndebord
As Deadlock is working on beta3, perhaps we should setup a sticky separate from the current one for him and consolidate his requests and our responses. What do you think?

He would have set it up alone - if he wanted it that way.

Guenter,

Yes, this beta thread is just fine.

N

Quote
guenter
There is a recent GRE 1.9.1.20pre that is build with Visual Studio 2005/VC8 and uses Dorian's patches for K-Meleon 1.6 variants @ http://dhost.info/kmeleonskins/1.9.1.20preVC8.7z

This GRE seems to work very well. I used a third party software to make all the file updates. I used SyncBack Freeware V3.2.26.0 found here: http://www.2brightsparks.com/freeware/freeware-hub.html#7

Since my profile is single and stored with the KM program files, it was easy. I just made a new folder called K-Meleon TEST and copied everything in K-Meleon there. Then I used SyncBack to copy every file from the gre folder after extracting with 7-zip. I included sub-directories and a rule that if the file existed in the source and existed in the destination, it should be copied from the source to the destination. A second rule was that if the file existed in only source or only destination, then do nothing to that file. After running SyncBack, I deleted the two dot dat files in components. Only thing left to do was to double click on k-meleon.exe and I was running just as before except the engine has moved from .17 to .20.

So far everything is working. I am doing this post on the test version. Guenter, thanks for posting the update file

@siria
You can visit http://useragentstring.com/ , select UA you like most and apply it via Tools->User Agent->Custom...
Here is my UA for Firefox 4.0.1:
Mozilla/5.0 (Windows NT 6.1; en-US; rv:2.0.1) Gecko/20110506 Firefox/4.0.1



Edited 1 time(s). Last edit at 08/23/2011 04:38PM by AirSpirit.

Firefox 4.0.1 - shipped in late April to fix eight flaws - was the one and only security update for Firefox 4.
With UA set to ff 4 users could have trouble visiting some popular web sites http://kmeleonbrowser.org/forum/read.php?12,116611

Plugin Check depends on buildID.
Should an option and comment be added to
Preferences/'Privacy and Security Settings'?

In KM 1.5.4 it was enabled by default.

I am no expert in this, but if buildID was enabled by default in 1.5.4 should we also enable it in new versions?

Just for user who doesn't know, what is buildID?

Also this plugin checker works if JS is enabled.
http://secbrowsing.appspot.com/

@JamesD
Some people don't like numbers.
KM 1.5.4 has a fixed buildID of "0000000000" in its GRE.

This buildID is an identifier for Mozilla applications.
It is build into GRE if MOZILLA_OFFICIAL is set in
development environment.

You can build a new GRE with that ID, use macros,
change it in chrome - to add an option in
"Preferences/Privacy and Security Settings",
or just use an override in defaults/pref/kmeleon.js.

pref("general.buildID.override", "0000000000");

If set, the plugin check will work as expected.

@Fred
Something for your next release?

@ndebord
Did you build your GRE with it?

@ deadlock

Thanks for the information. I decided to update the privacy section of 'defaults/pref/kmeleon.js' in all my KM browsers as follows.

//Introduce a buildID code as default - needed for plugin check site
pref("general.buildID.override", "0000000000");

Also needed to include http://www.mozilla.org/en-US/plugincheck/ in Policy Manager as requiring Javascript.

And yet another nice beta fix (that personally I may not really need, but many people do, have seen quite some "bug" complaints about it)

One general tip:
For user-added stuff I don't change the default js files, but create an extra one, so that it's not accidentally overwritten by an update! Goes especially for my user agents list, and mixed stuff I put into a file "my_othersettings.js" Names are completely free.

Quote
JamesD
to update the privacy section of 'defaults/pref/kmeleon.js' in all my KM browsers

So your suggestion for next beta is to enable it by default.

Quote
siria
mixed stuff I put into a file 'my_othersettings.js'

That is unexpected. Thought you use macros for everything.

For personal settings user.js was used with Netscape.
And you vote against adding it to next release?
Every release has small changes in kmeleon.js
that depend on the current version of program.

I should let siria answer for herself, but I don't think she disagrees about the default. I think it is just my method she thinks is not the best. Sounds like she is right for personal changes. Does an extra file ending in '.js' always get run at startup?

Thanks James, yes you're right. Little misunderstanding. My point was really only to keep *user changes* rather apart from default stuff. Of course I want that one as default too for future versions!
And yes, no matter which name, from that folder all js gets executed!

With user.js I'm not very familiar, but isn't that the one which can't be changed after startup?? For stuff like user agents that's not very handy, for stuff like this version it would be okay. But to have a personal change in all profiles incl. new ones, it must be set in a default folder, and then there's this prob again that default files can too easily be forgotten and accidentally overwritten at an update. Okay I admit, am already struggling to remember all the various places for default changes, and being happy with my method, am sticking with it

@JamesD
If she were right, were would it be added in a release version?
Since its origin is GRE, we could as well add it to greprefs.

Quote
siria
keep *user changes* rather apart from default stuff

So what is it for you? "User changes" or "default stuff"?
Another thing to consider is, that it was part of t-a-l-k-b-a-c-k.

Quote
siria
With user.js I'm not very familiar, but isn't that the one which can't be changed after startup??

You already wrote that macro, did you? MacroLanguage2?
You'll have to remove the pref-value to disable it,
since this would still work for plugin updates page:

pref('general.buildID.override', '');

Quote
siria
...then there's this prob again that default files can too easily be forgotten and accidentally overwritten at an update. Okay I admit, am already struggling to remember all the various places for default changes, and being happy with my method, am sticking with it grinning smiley

Yes, I agree. I have this long text file saved with notes of all the changes I must make when I get a new version of KM. I am going to see how much I can put into items that are not overwritten in new 7z or update KMs.

If I can manage it so that I have a 7z file which can add all my items to a new KM, that will be much faster. I already have a 'setup' macro which does most of the preferences that I need. I do worry about user agents. The number sequence must be correct. If KM changed the number of user agents there could be a gap or overwrite.

Quote
deadlock
You already wrote that macro, did you? MacroLanguage2?
You'll have to remove the pref-value to disable it,
since this would still work for plugin updates page:

pref('general.buildID.override', '');

I am not sure that I understand your question. I made changes in all my current beta KMs. That is just temporary for my current use. I am not sure to which macro you are referring. I have not done any macro for plugin check.

@JamesD
Sorry, that was for Siria.
Forgot to add @Siria at third line.

I was talking about a new release version.

Well, you're talking in riddles to me too.
Just not sure if you wanna kid me or we're just talking chinese :s *scratchhead*
You don't happen to confuse me with kko???



Edited 2 time(s). Last edit at 08/28/2011 09:42PM by siria.

@Siria
Never mind, it was unimportant.

Some people don't want to transmit
buildID with http-headers.

I still have no sample macro using MacroLanguage2
for beta testing and if you have a small macro for
deleting preferences it may be useful for buildID.

This is sample code only. It will run and set, change, or delete values.

BuildIDTest.kmm

#  K-Meleon Macros (http://kmeleon.sourceforge.net/wiki/index.php?id=MacroLanguage2)
#  
# ---------- BuildIDTest.kmm
# ---------- K-Meleon Macro Language Sample read, write, delete pref ---------------
#
# Dependencies        : main.kmm 
# Resources           : - 
# Preferences         : "general.buildID.override"
# Version             :  0.2   2011-08-28  JamesD
# --------------------------------------------------------------------------------

_BuildIDTest_Get_Pref {
$_BuildIDTest_Get = getpref( STRING , "general.buildID.override" );
alert( $_BuildIDTest_Get, "BuildID value is");
}

_BuildIDTest_Set_Pref {
$_BuildIDTest_Value = "1111111111" ;
setpref( STRING , "general.buildID.override", $_BuildIDTest_Value );
}

_BuildIDTest_Tog_Pref {
 togglepref( STRING , "general.buildID.override", "1111111111", "0000000000" );
}

_BuildIDTest_Del_Pref {
delpref( "general.buildID.override" );
}

_BuildIDTest_BuildMenu {
$_BuildIDTest_Popm = "BuildID Test";
setmenu("&Tools",popup,$_BuildIDTest_Popm,Misc);
&_BuildIDTest_BuildMenuP;
}

_BuildIDTest_BuildMenuP {
setmenu($_BuildIDTest_Popm,macro, "Get Pref", _BuildIDTest_Get_Pref, 0);
setmenu($_BuildIDTest_Popm,macro, "Set Pref", _BuildIDTest_Set_Pref, 1);
setmenu($_BuildIDTest_Popm,macro, "Toggle Pref", _BuildIDTest_Tog_Pref, 2);
setmenu($_BuildIDTest_Popm,separator, 3);
setmenu($_BuildIDTest_Popm,macro, "Del Pref", _BuildIDTest_Del_Pref, 4);
}

# ------------------------------------------
$OnInit=$OnInit."_BuildIDTest_BuildMenu;";
$macroModules=$macroModules."BuildIDTest;";

Wow James, what a quick service again (as usual)
(only wondering a bit why you split buildmenu even for such easy menus? Habit?)

Quote
deadlock
I still have no sample macro using MacroLanguage2 for beta testing

Hmm, somehow first your question and now this wording again makes me wonder a bit, if by ML2 you mean something different than James and I? IIRC (James may correct me) basically all KM versions since KM1.1 or newer are using the modern macros.dll that's supporting single macros in single kmm files, that was the last major version jump. Since then there were only occasionally added a few new functions, like iniread or $TabNumber etc. Delpref is rather old and exists since 0.9 too.



Edited 2 time(s). Last edit at 08/29/2011 07:06AM by siria.