the online installer first executes through a macro, to access the installer..right click on a kmext 7z link and select km extension

KEITH (part of KEM) will download the extension, decompresses it and extracts all files/folders in their designated destinations in kmeleon's folder.

please note, that the km extension menu command will always be greyed out(disabled) and will only be active on kmext.sf.net, this precaution is for 2 reasons:
1- ensuring the extension is in 7z format
2- ensuring the extension has the necessary uninstall ini for KEM

as an extensions manager, you can access KEM from the tools menu

clicking the drop down menu displays a list of the installed extensions

KEIH function's installing procedure is identical to KEITH only just for local files

note..that installing(web/local) and uninstalling extensions will close k-meleon and restart it. the functions also support kmeleons running with a loader.exe and additionally they will always delete compreg.dat and xpti.dat upon either installing or uninstalling ensuring that the components are always registered properly.

for an extension/macro to be supported by KEM, it must include an ini file containing instructions for the files that will be removed upon an uninstall..that ini file is naturally deleted as well.

for now, there are few extensions that are supported by KEM.. i've updated and uploaded about 20 or so but we have around 230 extensions and macros so updating all of them will take a while but hopefull will be done by this weekend

for now, if you'd like to test KEM.. you can download/install those extensions which have been updated

special conditions; for macro, tools and profile directory locations.. the ini may contain folders (without an ext suffix) for those 3 locations only KEM can delete folders as well as files listed in those places. for example if you have an extension that is created in a subdirectory in the tools folder..no need to list all the files in that folder and simply just add the folder name which will be deleted along with any files in that folder.

Cool. Me likey Suggestion: Since the the Extensions Manager is really just an extensions installation manager, how about changing the Extensions Manager menu item into a submenu item named simply, Extensions, providing a centralized location to list all the extensions' options? The first item in the list could refer to the installer, like Install/Uninstall followed by a separator then the extensions listed below. When clicked, their options(or function for those w/o options) would initiate.Ya feel me? Just a thought.

sorry, i didn't see the new thread when i made the post..guesss things are better organised now

update (preview-only) on KEM

displays number of installed extensions, install date and a small description for the selected extension..all read from the ini.. also the array display now remeoves the ini extension suffix so as not to confuse users. changes are not only cosmetic but several improvements for uninstalling..for ext. writes..the limitations have been expanded even more..technically..no longer have to worry about how many files or folders where..for e.g. there's support for up to 20 locales. ext/macro writers just need to follow the simple template to be supported by KEM.. an additonal part have been included (info) where the dev can write a brief description about their macro etc..it's optional..if KEM can't find it..then it will just display N/A .. hope you're happy now jsnj

by the way, alain.. ididn't remove the locales from microrss, i just uploaded it as it is from gary's website..i added the original locales from 1.4 but haven't uploaded it yet..also making autoit scripts localisable is proving more nightmarish everyday.. follow km locale is the proper way but the functional(somewhat easier) follow the os locale.. i'm not really sure how i'm going to solve this problem

preview of latest KEM updates

those are the extensions that now have complete support for KEM
23 done..about 200 to go

displays number of installed extensions, install date and a small description for the selected extension..all read from the ini.. also the array display now remeoves the ini extension suffix so as not to confuse users. changes are not only cosmetic but several improvements for uninstalling..for ext. writes..the limitations have been expanded even more..technically..no longer have to worry about how many files or folders where..for e.g. there's support for up to 20 locales. ext/macro writers just need to follow the simple template to be supported by KEM.. an additonal part have been included (info) where the dev can write a brief description about their macro etc..it's optional..if KEM can't find it..then it will just display N/A .. hope you're happy now jsnj

Just tested it and easily auto-installed about 40 ext from the site. Works great. Only bug is the installation date display in the manager. It reads that all of my extensions were installed on the 30th at the exact same time.

very stupid bug, thank you so much j for spotting it out.. i was concentrating so much on the info part, i forgot to do the refresh setdata at combo change for the date.. it's just setting the date for the first entry and not displaying any other

i've fixed it and uploaded revised one, download from same link

when uninstalling, be careful when testing with extensions like adblockplus or stylish, fireftp.. because the uninstaller will remove their settings files and folders from the profile so test with a secondary profile or even better test with a different kmeleon in another folder using different profile.. the uninstaller is unmerciful maybe it's not a very good thing but i believe an uninstall must a clean one

the above ini for example will transform kem into a kmeleon uninstaller..deleting the entire kmeleon folder contents and leaving only itself kmextman.exe in that folder.. the kmeleon profile folder will also be removed. the damage is only confined to kmeleon folder(and profile) but nothing else is affected(very ashamed

although not a single extension uninstall ini is malformed or can cause kem to remove kmeleon..it's a serious bug and had to be fixed.

the update address this bug so any malformality in an uninstall ini will no longer initiate an uninstall and kem will display an error message

additionally the bad ini will be removed and will not be displayed in kem next time its opened.

every single field line is now checked separately and even one error in a single line will prevent kem from uninstalling, displaying the error message and deleting the ini.

i'm very sorry for the previous kem(kmeleon-killer), the update has been tested vigorously on windows xp and 98 with numerous different malformed ini's and the bug was completely patched.

func openkmext()
$ask=MsgBox(32+4, "K-meleon Extensions Manager","You don't have any installed extensions. Would you like to download extensions?")
If $ask=7 Then
Exit
Else
run($openhome)
endif
endfunc

Quotedisrupted
also making autoit scripts localisable is proving more nightmarish everyday.. follow km locale is the proper way but the functional(somewhat easier) follow the os locale.. i'm not really sure how i'm going to solve this problem

And I thought it would be easy to localize the dialogs from Extensions Manager simply by translating the quoted texts in keit.au3 and kmextman.au3, but it's not .I hope You find a soultion.

How about offering a separate download link on kmext.sf.net for other languages, similar to K-Meleon en-US, de-DE, fr-FR etc?
I searched the Web and found a lot of extensions translated into polish (a few done by myself ), but on the Extensions Page you can find only a small amount with pl-PL locales included. It would make all the addons for K-Meleon more popular among the non-english speaking users. Of cource I could collect all existing translations and put them into .7-zip packages.

desga, i'm not sure if this will work because it will be a function setting a command for a different function so guictrlsetdata will not know what gui to modify..i'm doing a slight update for kem(it will be a surprise) and test adding the seperate function

actually matt after struggling with localising autoits for more than 3 months, i came to the conclusion that the best way is that for every language; the script is translated just as you've mentioned..it's not very hard..the text that will need translating in every script is very little..mainly labels and buttons. then the script is compiled and uploaded to a seperate folder..

for example german extensions:
kmext.sf.net/files_de/
etc

the slight problem which will need efforts form everyone is translating all pages to all languages supported by km..that is:
es, de, fr, pl, and ru

the translators will be responsible for:
1- maintaining the translated pages for their language
2- translating autoit scripts and compiling them

extensions which are chromes and macros only do not need to be localised and uploaded to the localised files folder(files_es, files_de etc) as many chrome(mozilla) have the locales and if not it's very easy to add a locale nside the jar and make a kml for the macro

translating and compiling autoit is very easy..just translating the few lines necessary in the script and compiling with autoit..for every extension, it won't take more than a minute ..this way better solution than messing up the scripts and rewriting everything so it can work from an external locale file.. using locales is alright for macros..in jars, it's no problem..the locale can be added inside and identified in the manifest.

just remember those guidelines for compiling autoit
1- the compiled file (exe) name must not be changed because it's called from the macro and sometimes it's called from other scripts
2- universal scripts(those that work on all windows version) must be compiled in ansi mode
3- scripts for nt must be compiled in unicode
4- scripts for windows 9x must be compiled in ansi

when you open the auoit compiler, just select ansi or unicode radio button before compiling..or a nice way i do it through the context menu of au3 scripts is adding 2 commands for au3 files in folder optons>file types
first command"compile in ansi": "I:\program files\autoIT\Aut2Exe\Aut2ExeA.exe" /in "%l" /icon "I:\program files\autoIT\Aut2Exe\Icons\main9x.ico"

the problem is who is willing to participate in the project.
i can translate autoit scripts into german but that's about it..my crappy german is not good enough for translating a website.. maybe gunter can help

french will be for alain, desga and aniatziag can do spanish, and anyone from russian team will do the russian(watsonrus or alex) and ofcourse you will do polish

remeber kmext is an open project for anyone to join in just like kmeleon, and several people have all the site details(passwort/ftp etc)

the pages are not too many..maybe 12 or so with not that much text either..mainly focus on extension pages and help, kplugins, plugins and disclaimer and credits pages are not important/not much to translate

if you like to translate the scripts and compile+ translating kmext.sf.net, i'll send you site ftp so you can upload..my email is openbsd6 AT googlemail , or you can contact gunter who has all the details.

Without using autoit, all the extensions had been translated using kml file (generally for menus and boxes used in macros) and locales in jar.

As K-Meleon handles locales, if the jar haven't the locale required, en-US is used by default. Same feature for kml files. So, all the extensions I put online have by default 4 kml files (es, de, fr, other). when installing, the setup looks for locales folder and installs all the needed kml. When a locale is found different from es, de, fr, it installs a untranslated kml file in this folder, and the user can translate it in his language (else en is used).

Wouldn't it be possible to read the strings in an inifile and to set variables which will be used in dialogs like I do it in SetDefault ?

In fact, after rereading it, I'm not sure that the SetDefault sample, even it's this type of technic which ought to be used, is the better sample.

Well, I send it. To make the read simplest, in function .onInit which is the start point, we set language which is set by a parameter. If a parameter is given, we jump to ReadLocale and translate variables (call Translate_Strings, else we call Messages_En.

Locale messages are now set and used in strings and dialogs.

NSIS his a language which isn't very usefull for this type of operations, so I have had big difficults to make it. I hope and think that autoIt3 is easier for this purpose, and I also think you will easily make it.
Instead of nlf file, you will probably use inifile which will be easy to use with autoIt.

Last thing, prefer use the locales\xx-YY folder to put and read the translations.
This folder is already use for k-Meleon and macros translations.

I'm sorry, but i just can not get this program to work. When I unzip on it and click the icon, it says you must run it from within kmeleon. But the program does not seem to be installed in kmeleon so I cannot get any grey menu bars by right clicking or anything like that. Is there a certain place i have to extract the extensions manager/downloader file to? Thank you so much for your time

Hi,
"extract to the K-Meleon folder" ...means: putting the files&folders from the unzipped extensions folder into their K-Meleons counterparts, e.g. those from "\kemNT4\kmextensions\" go to "\K-Meleon\kmextensions\", et cetera.
kmextman.exe and -.au3 go to the \K-Meleon main folder.
Unzippers usually can do this, but how to make them do it is not always ituitive to the newbie.