@JamesD
That's the header I was looking for.

@Siria
Looked here and found no comment
about MacroLanguage2 in my /macros folder.

Quote
siria
(only wondering a bit why you split buildmenu even for such easy menus? Habit?)

I never start with a clean page. I always start with something close, modify code, global replace names and save as the new name. I think PgLdSound.kmm was the model this time. Hey, I did remember to take out the rebuildmenu line.

You are right about the MacroLanguage. It has been this way for all the time that I have been coding for KM macros. When I did MacroLanguage2, I did not add anything at first. I only changed the organization of the information, and put an index at the end.

@JamesD
Removed the toggle and added it to beta.

thanks

Quote
deadlock
@JamesD
Removed the toggle and added it to beta.

That was just a 'test' example code. Are you going to leave it in TOOLS menu? Are you going to leave 'test' in the name? Are you putting the menu parts together?

@JamesD
>Are you going to leave it in TOOLS menu?
Yes

>Are you going to leave 'test' in the name?
No

>Are you putting the menu parts together?
No

Unimportant?

I am not saying this one is any better. It is just different. Location changed to 'Configuration'. I cannot go into 'Preferences'. Macroinfo statements added. Closed up the menu. No need to alarm users with stuff they might not understand. I did not understand before that you might use my code in the beta. Choice of which, how much to use is entirely yours.

BuildID.kmm

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

_BuildID_Get_Pref {
macroinfo = _("Display the value of general.buildID.override");
$_BuildID_Get = getpref( STRING , "general.buildID.override" );
alert( $_BuildID_Get, "BuildID value is");
}

_BuildID_Set_Pref {
macroinfo = _("Set a value of '1111111111' for general.buildID.override");
$_BuildID_Value = "1111111111" ;
setpref( STRING , "general.buildID.override", $_BuildID_Value );
}

_BuildID_Del_Pref {
macroinfo = _("Delete general.buildID.override");
delpref( "general.buildID.override" );
}

_BuildID_BuildMenu {
$_BuildID_Popm = _("BuildID");
setmenu("_Config_Settings",popup,$_BuildID_Popm,-1);
setmenu($_BuildID_Popm,macro, _("Get Pref"), _BuildID_Get_Pref, 0);
setmenu($_BuildID_Popm,macro, _("Set Pref"), _BuildID_Set_Pref, 1);
setmenu($_BuildID_Popm,separator, 2);
setmenu($_BuildID_Popm,macro, _("Del Pref"), _BuildID_Del_Pref, 3);
}

# ------------------------------------------
$OnInit=$OnInit."_BuildID_BuildMenu;";
$macroModules=$macroModules."BuildID;";

Yep, the config placement is certainly a lot better
But I understood it first as a demo macro, how delpref etc. works.
Now if it's for actual use, perhaps one simple toggle macro would be better, instead of a multi-choice popup menu?

Thinking about it again, and being a serious paranoia freak (on the web), but not sure why hide a default entry that seems to always simply be 000000?



Edited 1 time(s). Last edit at 08/31/2011 08:53PM by siria.

@ siria

Good idea. Just all depends on what deadlock wishes. I have no preference.

After reflecting on this overnight, I have a question. Is it a change in value for BuildID or the complete absence of the pref that is desired?

@siria
>why hide a default entry that seems to always simply be 000000?

"0000000000" is a default value set by GRE <= 1.8.1. and
the header entry itself is specific to some browsers.
But correct me if I'm wrong.

@JamesD
>or the complete absence of the pref

In this case testing would have been faster than reflecting.

Never used the new macros and settings that came with 1.6b2.
Looks as if someone added his personal user settings.
Main.kmm changes the behavior of urlbar and that would be
one good reason why some people prefer alpha version.

I've added buildID option for testing:
http://dhost.info/kmeleonskins/KM1.6b3/base/macros/main.kmm

BuildID should only be set in prefs.js
and can be enabled/disabled without restart.

Test with mozilla plugincheck.

@ deadlock

The new main.kmm works quite well. Sorry to be late testing. Was away from home part of yesterday.

@JamesD
>I have no preference.
You can add it to all menus.

>The new main.kmm works quite well.
Your macros also work well.

Is there anything else to
change in that file?

>Sorry to be late testing.
I don't think you were late.
As long as you don't have another
sleepless night reflecting IDs.

Quote
deadlock
Is there anything else to
change in that file?

I use the Mozilla capability policy prefs because I run the Policy Manager extension. In that I have Javascript on in prefs, but have the 'capability.policy.default.javascript.enabled' pref set to' noAccess'. I have made changes to main.kmm so that items like 'Send page as a link', 'zoom image' and other will still work.

I don't know what percentage of users use capability policy. I don't think the inclusion of my code would impact anything else.

All the lines with $FlipFlip are lines I added to bypass the default for an immediate injectJS.

# Parameters for JS_hndlDoc(s) (set those you need before calling the macro):
$JS_doit=""; $JS_func=""; $JS_last=""; $JS_fail="";
JS_hndlDocs{
# $JS_doit takes the code to be executed in the context of each frame
# $JS_func is the right place for functions and global variables (e.g. when you want to count something over all frames)
# $JS_last is the right place for finishing actions (e.g. when you want to alert what you have counted over all frames)
# $JS_fail is the right place to handle errors that may occur when accessing a frame (Gecko prevents cross-site scripting)
$FlipFlip = false;
getpref( STRING, "capability.policy.default.javascript.enabled")=="noAccess" ? $FlipFlip=true : 0 ;
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
injectJS("(function(){".$JS_func.$_JS_urlencode."function hndlFrm(w){try{with(w.document){".$JS_doit."}}catch(e){".$JS_fail."}for(var j=0,f=w.frames;j<f.length;j++)hndlFrm(f[j])}hndlFrm(window);".$JS_last."})()");
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
$JS_doit=""; $JS_func=""; $JS_last=""; $JS_fail="";
}
JS_hndlDoc{
# Same as JS_hndlDocs, but only for the current frame.
$FlipFlip = false;
getpref( STRING, "capability.policy.default.javascript.enabled")=="noAccess" ? $FlipFlip=true : 0 ;
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
injectJS("(function(){".$JS_func.$_JS_urlencode."with(document){".$JS_doit."}".$JS_last."})()",frame);
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
$JS_doit=""; $JS_func=""; $JS_last=""; $JS_fail="";
}
JS_hndlTop{
# Same as JS_hndlDoc, but only for the topmost frame (to avoid cross site scripting).
$FlipFlip = false;
getpref( STRING, "capability.policy.default.javascript.enabled")=="noAccess" ? $FlipFlip=true : 0 ; 
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
injectJS("(function(){".$JS_func.$_JS_urlencode."with(document){".$JS_doit."}".$JS_last."})()");
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
$JS_doit=""; $JS_func=""; $JS_last=""; $JS_fail="";
}

@ deadlock

While you are fixing things, there is one misspelling that I need to mention. It is my fault. I just did not check a dictionary before I released the code. In beta2 there is a troubleshooting.kmm macro. The spelling of 'privilege' is incorrect. I included the letter d when I should not have done so. The misspelling is pervasive in the macro. Could you do a global change on troubleshooting.kmm please.

Edit: There are some uppercase instances so replace 'riviledge' with 'rivilege'.



Edited 1 time(s). Last edit at 09/03/2011 02:48AM by JamesD.

Quote
deadlock

Main.kmm changes the behavior of urlbar and that would be
one good reason why some people prefer alpha version.

Could you expand on this? I hadn't noticed. How has the urlbar behavior been changed by Main.kmm in the beta? Which section in the file?

@JamesD
>replace 'riviledge' with 'rivilege'
done.

A) Where are the resources?
Can't find them in KM 1.6b2:
Resources: privilege.ini, privilege.htm, large-alert.png

Is troubleshooting.kmm a good name
for privilege configuration?

C) Does it require NTFS file system
permissions for testing?

D) I didn't test it yet, but do you know
how many people are actually using this macro?
I think it needs a description and should be
added to MacroLibrary.

Just days ago gordon posted something about "elevated administrative rights" in newer systems (was in Feebies Thread). That got me curious and went to google a bit, and that stuff is really quite interesting! I feel it's really one of the main probs in KM, that it simply doesn't do anything, if a user is missing writing rights. Nothing. Eventually the user notices his configurations weren't stored, and I don't wanna know how many of them drop that thing immediately then

In XP there was this folder security stuff, complicated enough already for clueless users (incl. myself here). Even people who know how to adjust folder rights, I suspect many of them may not feel like switching windows user for every little bit of configuration, not to mention storing bookmarks etc. Since hardly anyone realizes their "single user setup" is what makes their profile write-protected.

But in Vista things got nearly impossible. I got me a new laptop myself some two years ago, which to my regret was only avaible with Vista at the time. That idiotic crap cost me half my hair with anger and enourmous time wasted!!! It wouldn't let me do anything on my own machine, and with LOTS of work just got it half-way working, but finally gave it up completely. Only use it since for the rare cases when I need a fast system, e.g. for video stuff. Yeah I know, one can learn that stuff step by step, but for now I'm fed up, and wasted more than enough time. Love my old system way too much anyway, and as long as it survives, I'll stick with it.

Anyway, I think this issue needs some updates urgently. If KM can't save something, there should be a system popup asking the user for permission, instead of just silently doing nothing!
And it looks like there are ways to do this, perhaps with manifests??? As explained in wikipedia:
http://en.wikipedia.org/wiki/User_Account_Control

That article had quite some enlightening info for me, about rights-management in Vista/Win7, and it was really interesting to read... Got the impression that Microsoft simply "renamed" all user-rights one step lower, since most people were surfing the web with an admin account... Now an "admin" seems to have only "a bit higher default rights", and that's tricking people into thinking they had full rights. But to get "real" admin rights, one has to switch to "elevated admin rights", which isn't widely known among ordinary users! And win7 (and Vista?) are storing settings stuff not in the programs folder anymore, if a programs tries to do this (=portable KM), but in a special folder in his appdata - which hardly any clueless user knows either! So how to find it?



Edited 1 time(s). Last edit at 09/04/2011 02:30PM by siria.

@jsnj
>Could you expand on this? I hadn't noticed.
>How has the urlbar behavior been changed
>by Main.kmm in the beta? Which section
>in the file?

I didn't test all open functions yet.
I replaced main.kmm while fixing
problems in my code and it took a while
until I realized, that there was no
new bug in the beta.

It was only a new feature that displays
the query without opening it.

This line
$OpenURL==""?0:$URLBAR=$OpenURL; $OpenURL==""?0:id(ID_NAV_GO);
was replaced by this:
$OpenURL==""?0:$URLBAR=$OpenURL; $OpenURL==""?0:&_OpenURL_HowST;

Old main.kmm:
I type a search term in the address bar
press <CTRL+G> and the search engine page is
opened right away.

New main.kmm:
Now I type a search term in the address bar
press <CTRL+G> and nothing happens.
It requires an additional <enter>.

Not sure who invented _OpenURL_HowST,
but there are unused options like
kmeleon.forceTab in K-meleon.

Ctrl+G works fine for me in 1.6b2, no prob. No additional Enter needed. That ...howST macro also works fine.
No idea why, perhaps it's influenced by some other setting??

Quote
deadlock
@jsnj
>Could you expand on this? I hadn't noticed.
>How has the urlbar behavior been changed
>by Main.kmm in the beta? Which section
>in the file?

I didn't test all open functions yet.
I replaced main.kmm while fixing
problems in my code and it took a while
until I realized, that there was no
new bug in the beta.

It was only a new feature that displays
the query without opening it.

This line
$OpenURL==""?0:$URLBAR=$OpenURL; $OpenURL==""?0:id(ID_NAV_GO);
was replaced by this:
$OpenURL==""?0:$URLBAR=$OpenURL; $OpenURL==""?0:&_OpenURL_HowST;

Old main.kmm:
I type a search term in the address bar
press <CTRL+G> and the search engine page is
opened right away.

New main.kmm:
Now I type a search term in the address bar
press <CTRL+G> and nothing happens.
It requires an additional <enter>.

Not sure who invented _OpenURL_HowST,
but there are unused options like
kmeleon.forceTab in K-meleon.

Never looked at that code before, but Desga2 created that in response to a request some users had to separate the search button open url behavior from the global URL Bar behavior pref. For example, one might want to open typed URLs in the same tab, but typed search querys in a new tab. Looking at the code though, I can't see how that would trigger the bug you are getting. That seems more like an accelerator issue. If nothing happens after typing CTRL G, pressing ENTER alone shouldn't call a macro. Just speculating but it seems when you press ENTER it calls the URL Bar autosearch feature (keyword.url pref) which may be the same engine as your default search engine?

The main problem I have with the change though is that it alters what is meant to be a "global" macro, if you will, that other macros can use to mirror global URL Bar behavior, just for one specific macro. Now all external macros/extensions that call the OpenURL_Typed macro are bound by the pref a user has set for the search button. I'm not sure if he did it that way for a particular reason I may be overlooking, but it seems the change would be better implemented in search.kmm. Having said that, I doubt many users would have noticed because I don't think there are many macros that call OpenURL_Typed.



Edited 1 time(s). Last edit at 09/04/2011 07:40PM by jsnj.

Quote
deadlock

A) Where are the resources?
Can't find them in KM 1.6b2:
Resources: privilege.ini, privilege.htm, large-alert.png

Is troubleshooting.kmm a good name
for privilege configuration?

C) Does it require NTFS file system
permissions for testing?

D) I didn't test it yet, but do you know
how many people are actually using this macro?
I think it needs a description and should be
added to MacroLibrary.

A. They appear to be missing. $_Priviledge_WarnPath should point to
priviledge.htm and large-alert.png was used on that page. It had information about write authority and a warning that the user did not have it for their profile folder.

B. That is the name desga2 gave it when he included into beta 2.

C. Any file system should work. If KM can write an ini file to profile folder then user has write authority for profile folder.

D. There was a time when many more novice users were asking questions and a large part of the questions involved knowing if the user had write authority to her/his profile. It just seemed better if there was an easy way for the user get that answer. As for Troubleshooting as a name: it fits. Also I think desga2 was planning for a system which might have more items than just Privilege.

I am away from home and this laptop does not have all my old stuff. Maybe I can find those pieces when I get back home next week.

@jsnj
>I don't think there are many macros that call OpenURL_Typed.
I found some.

Thanks for your explanation.

The S and T in _OpenURL_HowST are for search and typed.
I'll add a comment above that line.

The problem is that OpenURL_Typed now overrules
several global settings without testing
for existence of:
1) kmeleon.plugins.macros.searchtyped.openurl
2) _OpenURL_HowST

OpenURL_Typed should use global settings
if one of them is undefined.

It ignores other options like tabs disabled and kmeleon.forcetab.

This line was missing in my defaults/pref/kmprefs.js.
pref("kmeleon.plugins.macros.searchtyped.openurl", "opentab");

The pref can be changed in preferences dialog:
Preferences/Browsing/Finding Websites/Search Button
and has no default value!

There is a combo box for opening:
Preferences/Browsing->General->Open->Typed URLs
It changes this pref:
pref("kmeleon.general.openurl", "ID_OPEN_LINK_IN_NEW_WINDOW");

".searchtyped." should be added to the combo box:
Preferences/Browsing->General->Open->Typed Search URLs
and this page can be removed:
Preferences/Browsing/Finding Websites/Search Button

Some more changes?
If you look at
Preferences/JavaScript/Popup Windows
and compare it with
Preferences/Page Display/Content Filters
and with
Preferences/Browsing/Window Diversion
it is cluttered and has duplicates.

@ deadlock

I did find the Privilege.kmm files. The were on my Dropbox account. I have fixed the spelling and they can be found at: http://dl.dropbox.com/u/1522294/Privilege.7z

The htm and png files perhaps should go in chrome and skins/default but I don't know how to use chrome.

@JamesD
A. The comment about resources can be removed.
B. I don't like it.
C. I suppose it works.
D. A link to faq will help.
The description in Preferences/macro extensions
could use the word 'privilege'.



Edited 1 time(s). Last edit at 09/05/2011 03:23PM by deadlock.

The macro isn't meant for configuration of priviliges, nor anything else, and it couldn't. The sole purpose was to help people when they have trouble, to easier do a quick test if they have writing rights or not :cool: It think too a troubleshooting.kmm is a great idea, and it could be expanded over time Better yet of course, if it could actually fix missing rights and such, but guess chances are tiny. That's a bit too difficult for macros. Perhaps manifest settings or such would help to reduce such probs from the beginning??

@siria
Who said it configures?

I said the description in
Preferences/macro extensions
could use the word 'privilege'.

Inspired by 49 occurrences of
the term "privilege" in 56 lines
of troubleshooting.kmm.

Quote
deadlock
I said the description in
Preferences/macro extensions
could use the word 'privilege'.

I do not know how to fix that description.

Regarding the resources, the Privilege folder was replaced with "about:mozilla" when desga2 created Troubleshooting.kmm for beta2. Looks like the png file and text are there.

Quote
deadlock
Inspired by 49 occurrences of the term "privilege" in 56 lines of troubleshooting.kmm.

Good point Of course curious me had to take a look now too - and the replace function really announced 51 hits! Yes, it's quite impressive

I realize the all the names are not global, but I have just got into the habit of following that standard for naming variables.

Quote
http://kmeleon.sourceforge.net/wiki/MacroGuidelines
The names of all macros and global variables defined in module <modulename> must have <modulename>_ as a prefix!

In your module, a macro name like "Open", for instance, isn't very specific. Another macro coder could use the same macro name in another module. Users who now install both modules would end up getting a macro redefinition error. When you call your macro <aName>_Open and the other macro coder calls his macro <anotherName>_Open, such collisions will never occur. Since the module name must be unique anyway, the module name is the appropriate prefix. (And when you see a macro <name1>_<name2> somewhere in a toolbars.cfg for instance, you know that it's defined in <name1>.kmm)

If you think the count of "Privilege" is high in this macro, you should see one of my longer macros.

@Siria
At least you we're smiling.

@JamesD
>I realize the all the names are not global ...

What on Earth are you talking about?