@ JohnHell

We are both correct. The menu.bmp file is only one level. The correct status should have applied to tools0.bmp which has three levels. The problem occurred when I added the menu.bmp file to skin.cfg in order to put all the icons in skin.cfg. I forgot to remove the command names from the commands list for menu.bmp that were already in the commands list for tool0.bmp. I have removed the duplicates and everything is working correctly. Thank you for your help.

My skin no longer requires the file menuicons.cfg.

I have updated the 7z file for my Klassic2 skin.

https://copy.com/9OKXTArssEl9LKmk

Regarding your skin, namely the navToggleJS:

Quote
JohnHell

togglepref(BOOL,$pref_JavaScript); id(navToggleJS); &_pref_SyncButtons;

On a side note:
Did you manage to solve the issue with images which don't change on toolbars created by macro?

Quote
Yogi
Did you manage to solve the issue with images which don't change on toolbars created by macro?

I have just this evening put navToggleJS into my "toolbars.cfg" files. It is, I think, a command name. It does not have a "state" like a pref of type BOOL.

I am working on updating the K75t.kmm file. I can make new image appear on the button most of the time. I am on holiday this month and my laptop does not have all the support files and programs that I use. No idea when I can finish. March?

Beta 3 is better than beta 2 at changing images on macro created buttons.

Quote
JamesD

I have just this evening put navToggleJS into my "toolbars.cfg" files. It is, I think, a command name. It does not have a "state" like a pref of type BOOL.

That's right but without replacing that line, blocking JavaScript instantly on a page, doesn't work with the Klassic skin.

Quote
JamesD

I can make new image appear on the button most of the time.

Good to hear that it is possible to solve the issue with images on a toolbar created by a macro - at least most of the time.
I'm afraid it's partially related to the new skin format.

Enjoy your vacation!
I won't bother you with other questions till you are back home.



Edited 1 time(s). Last edit at 02/09/2015 11:53AM by Yogi.

@ Yogi

Don't worry about asking question. I just may be slow to answer.

I have the button working for Javascript in page. My question is does the command remain from page to page or must each page have the command executed for the page? Should I set the "state" of the new tracking pref back to the default at each page load?

I'm not sure, I understood your question.
Toggling JavaScript on and off works as it always worked. No extra button only the usual one from the PrivBar.
The only difference with the new command is that you can stop now instantly the execution of JS on pages which have been loaded with scripting enabled.
Prior you had to refresh the site that was loaded with scripting enabled, before the JS toggle (off) took effect.

JS gets disabled globally and the "state" persists as long as you don't activate JS again.
You can check here by opening more tabs.

That's how the pref_ToggleJavascript looks by default in KM 75b3, but only works for the default skin:

pref_ToggleJavaScript{
macroinfo=_("Toggle JavaScript execution");
menuchecked=!getpref(BOOL,$pref_JavaScript);
togglepref(BOOL,$pref_JavaScript); &_pref_SyncButtons;
statusbar(sub("%s",!getpref(BOOL,$pref_JavaScript)?$off:$on,_("JavaScript execution %s")));
}

And that's how the pref_ToggleJavascript looks now for working also with the Klassic skin (Kudos to JohnHell for telling me):

pref_ToggleJavaScript{
macroinfo=_("Toggle JavaScript execution");
menuchecked=!getpref(BOOL,$pref_JavaScript);
id(navToggleJS); &_pref_SyncButtons;
statusbar(sub("%s",!getpref(BOOL,$pref_JavaScript)?$off:$on,_("JavaScript execution %s")));
}

OK, if the state persists then I am almost ready.

About the buttons by macro, I have an updated K75t.kmm ready.

https://copy.com/Oh1z7sa2r2WvDyEs

Not tested yet, just asking. Does that test.kmm only work for the new skin format?

Quote
Yogi

Quote
JamesD

I have just this evening put navToggleJS into my "toolbars.cfg" files. It is, I think, a command name. It does not have a "state" like a pref of type BOOL.

That's right but without replacing that line, blocking JavaScript instantly on a page, doesn't work with the Klassic skin.

Actually it has a Boolean, as the command id changes the javascript.enabled preference too. The new command id what does is enhancing the javascript.enabled preference to take effect immediately, not as before, that there was the need to reload the page.

But this has nothing to do with the skinning/new skinning format. I mean, there is nothing to change in any skin as they are, or should (mine may be the exception) call the macro pref_ToggleJavascript. The only need is to change that macro.

The definition in the skins should remain as macros(pref_ToggleJavascript) for the index (of an image with more than one icon) of the image used.

@JamesD

I've tested the buttons created by macro. I have to hover with the mouse after toggling in order to change the image.
The promising thing however is that it does change the image in my Klassic skin too.

Good to know that the new command changes the JS pref. The fix for my setup will be simple now.

I have an update planned for K75t. Just need time to do it and test.

I have a new version of K75t.kmm and support files. I could not understand image strips with setcmdicon so I got some individual images.

See here: https://copy.com/Oh1z7sa2r2WvDyEs

EDIT:
I have a revised K75t.kmm at https://copy.com/Oh1z7sa2r2WvDyEs


All of these commands work.
# addtoolbar(name)
# addbutton(toolbarname, command, menu)
# removebutton(toolbarname, command)
# setcmdicon(name, image, width, height, HOT, COLD)

Note that there is still a problem where the first image change does not get the correct image. It usually shows the forward arrow image. I suspect there is an index, register, or counter that is just not finished yet.

There does not seem to be a place to put a tooltip, but there is a right-click menu for the first button.

I hope this is useful for training and testing.



Edited 1 time(s). Last edit at 02/12/2015 09:21PM by JamesD.

Quote
JamesD
setcmdicon(name, image, width, height, HOT, COLD)

I finally tried that in Vista with KM75beta3 and the "default" skin. Looks like the first "image" adds an icon in menus, that was so far only possible with a menuicons.cfg in the skin folder, not via macro.
But the Hot+Cold pics at the end do absolutely nothing on that machine. You have win7, either it's a system thing or I'm doing something wrong. You really sure it works?

The menuicon shows the page-forward-arrow instead of the image when width and height are not put in quotes: e.g. "16","16" work okay.

All the traditional commands incl. pluginmsg-"CheckButton" and pluginmsg-"SetButtonImage" still work fine too.

Except that pluginmsg-"SetButtonImage" in 75beta3 only works on the cold image (=unpressed), but that might have to do with the same bug as pressed-button-pics, we'll see when that one gets fixed.
Still working example:
$_x="COLD,adblockplus.bmp[1]";
pluginmsg(toolbars,"SetButtonImage",$toolbarname.",macros(ABP7_Toggle),".$_x);

And tooltips still work fine when defined in the "addbutton" line.

All in all traditional macro-created buttons still work exactly the same as in previous KM versions, with the same commands, except for that little bug with the hot image yet. For the moment that can be worked around (example in adblockplus-macro).
KM75 only adds a brandnew, before not possible command that can set menuicons.

PS: Had no clue a "removebutton" command exists too - something learned again



Edited 6 time(s). Last edit at 02/17/2015 11:38PM by siria.

Quote
JohnHell

Quote
JamesD
I have just this evening put navToggleJS into my "toolbars.cfg" files

Actually it has a Boolean, as the command id changes the javascript.enabled preference too. The new command id what does is enhancing the javascript.enabled preference to take effect immediately, not as before, that there was the need to reload the page.

GRRRmpf - that sounds like what I was suspecting, knowing mozilla
But usually I want to load a page *without* scripts, and then only inject a bookmarklet or user script, NOT start all those page crap scripts too
If I read you right now, that's the same gecko mess as when the adblock-toggle started (in KM1.5? 1.6?) to automatically load ALL ads in ALL pages, taking endlessly, while all I want is to allow it in the *next* loaded page, as it worked in the past!
Or the animated images, in the past toggling that pref only allowed them in the next loaded page. Just my needs. But since KM1.5/6? I have to wait endlessly until my 50 tabs are finally done loading ALL animated images in ALL tabs and nearly killing my old machine. Hate those automatics!!

Or do I get you wrong, and with "before" you mean only that nonsense "before as in first KM75 betas"? And otherwise the page scripts still need additional reload? Sure wish... please say so...



Edited 1 time(s). Last edit at 02/17/2015 09:26PM by siria.

Quote
siria
You really sure it works?

It does on my win 7 laptop. There is one bug. When I use menu to create second button, the cold state is a blue notepad and the mouse over (Hot state) is an orange notepad. If you click on the button the image changes to the forward arrow. That is the bug. If you click again, the button is back to its original state. That is what the macro does. If you click a third time, you miss the bug and the cold and hot images are different. They have become a yellow notepad for cold and a green notepad for hot. Continued clicking on the button keeps swapping the notepad colors.

I am away from home so I cannot try K75t.kmm on an older operating system.

@Siria, Dorian fixed it in K-meleon 75 beta 3.

JavaScript toggles without page reload.

What I was telling JamesD is that the navToggleJS toggles the preference javascript.enabled too, because he looked in doubt of a parameter/status to check, so there was no need to change the command for the skin icons and/or macros.

When toggled JavaScript we still can check the javascript.enabled status to know how it is and change icons.

In other words, Dorian made navToggleJS on top of the javascript.enabled preference so it makes the toggle immediately effective and change the value too for new tab/windows loads.

Hmm... sorry, not sure I fully understand, still sitting on the cable, as we say here ;-)

As practical example, lets say you have loaded a youtube page without JS.
Now if you toggle "js.enabled", the page still does nothing, I suppose?
If you now call a bookmarklet, it didn't work in first betas.
Does it now - or still not?
If not, and you use now navToggleJS, the bookmarklets probably work, but what about the page scripts: do they still need a manual reload to work or not?

Sorry, there's just not the tiniest bit trust left in mozilla now.

Quote
siria
Hmm... sorry, not sure I fully understand, still sitting on the cable, as we say here ;-)

As practical example, lets say you have loaded a youtube page without JS.
Now if you toggle "js.enabled", the page still does nothing, I suppose?

Correct.

Quote
siria
If you now call a bookmarklet, it didn't work in first betas.
Does it now - or still not?

Still not.

"javascript:whatever" as bookmarklets or as a simple link in a page with an "href="javascript:whatever;"" won't work unless you reload a page with javascript enabled.

The bookmarklet functionality is still broken. The call to javascript independent functions (run on the fly as for example an alert) is still broken.

I haven't requested this to Dorian to dig because I don't have the answer and maybe he have to dig a lot in the source code to make work what Mozilla disabled.

With this feature is still "all or nothing".

Quote
siria
If not, and you use now navToggleJS, the bookmarklets probably work, but what about the page scripts: do they still need a manual reload to work or not?

Sorry, there's just not the tiniest bit trust left in mozilla now.

To the last thing, if you enable javascript again, after laod, the scripts on the page won't work, as it was in old K-meleon versions, except that now won't work "javascript:whatever" either, when this worked before.

The only way to run javascript with javascript disabled (to ensure it runs whether JS is on or off at load time) is to use injectJS, maybe you could port your bookmarklets to injectJS macros.



Edited 1 time(s). Last edit at 02/17/2015 11:34PM by JohnHell.

Okay, that sounds not as bad as feared. Thanks for explaining in detail
If I get it right, toggling navJS ON basically is useless currently. If bookmarklets don't work (guess have read somewhere that Mozilla disabled open(js..) for 'security' reasons), and injectJS now works great again without need to have js active, it makes no difference.
Converting bookmarklets to macros is no prob for me, but probably most others, and not very handy anyway. Reminds me to some day continue work again at stylescriptia/styleon macro again, ouf.

But toggling navJS OFF is probably still most important, if this can block loaded page scripts, and then using injectjs again.



Edited 1 time(s). Last edit at 02/18/2015 12:14AM by siria.

Quote
siria
Converting bookmarklets to macros is no prob for me, but probably most others, and not very handy anyway.

Most of avarage users probably never disable/stop JS, so not much problem for them. The bookmarklets will work for them.

It is just us, we are extreme xD

Quote
siria
But toggling navJS OFF is probably still most important, if this can block loaded page scripts, and then using injectjs again.

And just to be clear, it does the bolded.

You may be interested in pageToggleJS too, if you didn't read the 75b3 release notes:
http://kmeleonbrowser.org/forum/read.php?8,131989
"- added navToggleJS (toggle js pref and js in all page) and pageToggleJS (toggle js in current page) "


END OF OFF TOPIC FOR ME