Will it plan any Extensions System in K-Meleon ? (xpi or other)

And Is it any plans for converter from FF xpi to KMeleon xpi.
(imho that convertion needs only for XUL GUI to convert it to KM GUI macros, if it possible)

It would be the great futures to expand KMeleon functionality !!!



Edited 2 time(s). Last edit at 05/09/2007 12:37AM by D555.

1.) http://perso.orange.fr/jujuland46/JujuLand/KMES/KMES-Generalities.html

K-Meleon can use the SeaMonkey xpi installer when You install the infra structure but this does not help. You still need to create the K-Meleon start macros.

K-Meleon has no XUL GUI. Most of the XUL infrastructure will never be available for
K-Meleon.

I'm about to finish a little modification on the script.

It just concerns the compression which will not use upx anymore, but internal compressor. This will make setup 20% smaller.

I also suppress the language box. The language will be choosen automaticly, and if the language isn't include in the steup, English will be choosen.

The content, except for Localization setups, ought not to be changed with this version which will be now 1.7.0.

A+

---

Mozilla/5.0 (x11; U; Linux x86_64; fr-FR; rv:38.0) Gecko/20100101 Ubuntu/12.04 K-Meleon/76.0

---

Web: http://jujuland.pagesperso-orange.fr/
Mail : alain [dot] aupeix [at] wanadoo [dot] fr

---

Ubuntu 12.04 - Gramps 3.4.9 - Harbour 3.2.0 - Hwgui 2.20-3 - K-Meleon 76.0 rc

---

So many good news ..

And is there any instructions to modify FF plugins to make it full workabe with KM ?
Looking in FF .xpi find only .xul files from FF GUI imho to translate ..
What can do to translate it to KM extensions or script folders ?



Edited 1 time(s). Last edit at 05/09/2007 08:34AM by D555.

Quote
JujuLand
It just concerns the compression which will not use upx anymore, but internal compressor. This will make setup 20% smaller.

I toll you it.

Default internal compressor is better than UPX.

K-Meleon in Spanish

The best way to adapt an Mozilla extension to K-Meleon is:

1) install it with a mozilla browser
2) look at the files which has been installed (chrome, components, js, ...)
3) Copy these files in corresponding folder under K-Meleon
4) create the manifest file (sometimes present in xpi, but needing modifications)
5) Open jarfile and look for xul files
6) Create a kmm file (macro) to try all xul files (don't test overlay*.xul)
7) Create menus needed (in kmm file) to use the product and often to simulate menus added in Mozilla browser.
8) Create a toolbar, if needed (see microrss)

Generaly, extension which use panel doesn't work or hardly.

Some like Foxlingo can perhaps, but it must be modified, and it's harder for me, and I don't find a great interest for K-Meleon.

A lot of extensions don't and won't work.

A+

---

Mozilla/5.0 (x11; U; Linux x86_64; fr-FR; rv:38.0) Gecko/20100101 Ubuntu/12.04 K-Meleon/76.0

---

Web: http://jujuland.pagesperso-orange.fr/
Mail : alain [dot] aupeix [at] wanadoo [dot] fr

---

Ubuntu 12.04 - Gramps 3.4.9 - Harbour 3.2.0 - Hwgui 2.20-3 - K-Meleon 76.0 rc

---

guenter
I should suggest new part of Forum named "Extensions" where people can posting about translated(FF) or new extensions or wish for translation-(FF)extension for KM !

And have another wish - an extensions manager in KM !



Edited 1 time(s). Last edit at 05/27/2007 09:45PM by D555.

Quote
D555
guenter
new part of Forum named "Extensions" where people can post

This is my wish also. Else an extra part in the wiki or an extra home page for them.

Quote
D555
guenter
And have another wish - an extensions manager in KM !

Look in 1.1 Advanced Preferences - kko made a extension manager for k-meleon extensions.

The chrome part of an extension can be deleted and the manifest also,
they are modular and deleting does not effect k-meleon's chrome.

We can not have more chrome management at the moment until SeaMonkey has shifted to "Toolkit" backend that Firefox has also. We will probably get their manager for free as soon as they shift

The current xpi installing system of SeaMonkey is not good/unsafe so kko and me only looked whether the installer process would work.

Own home page for extension - should be very great (lke addons.mozilla.org i see)

A few words for vote for .xpi .
Imho noone extensions system can't guarantee 100% safety ... But .xpi be more compatible with existant FF extensions.
Problem would be solved by permission system and digital signature like in FF, i think.



Edited 3 time(s). Last edit at 06/02/2007 11:28PM by D555.

agreed - XPI is IMHO the most effective installer solution - we only need a script and a zip program to make (pack & unpack/install) or own extensions.

But:

XPI will not help us much with Firefox type extensions because we do not have the XUL interface into which FFox & co. hook the starter buttons or starter menu items

So You would still need ppl such as Wladimir Palant that want to make their extension available for all browsers.

With the rest? Likely that many ppl will instal FFox extensions and later come here and complain that they do not work

I installed the NoScript extension ( which has a SeaMonkey version ) after installing our old fashioned SeaMonkey xpi installer service. Then I hacked the XUL so that we do not see the things we do not use and made a starter for the settings interface. Then I waited a couple of weeks until alain had spare time to implement the rest for us

So all we get is that we reduce the initial step of making an extension usable, we still have to adapt it and I am not sure whether this "XUL-only-preinstall" is worth the reduced security.

Possibly best only to make XPI installer service itself an optional installable package for ppl that want to try whether some Extensions may/will work.

But that is easier to have (even now) - You just place all unique k-meleon components into a complete SeaMonkey folder. Now that will give You a "XUL-only-preinstall"environment for SeaMonkey extensions and old, pre 1.5 Firefox extensions.



Edited 1 time(s). Last edit at 05/29/2007 10:37AM by guenter.

I've haked .xpi too - therefore
the idea was in easy modify .xpi for work with KM. Imho it needs just put on place(instead) of .xul interface files - .kmm files in .xpi package.
May be it needs some detaled instructions(SDK ?) for people to easy start translate .xul into .kmm by wide masses of people .



Edited 1 time(s). Last edit at 06/02/2007 11:37PM by D555.

Quote
D555
I've haked .xpi too

good, did You find a usefull one?

Quote
D555
therefore the idea was in easy modify .xpi for work with KM. Imho it needs just put on place(instead) of .xul interface files - .kmm files in .xpi package.

Yes You are completely correct; that is the way.

kko and I made that what You say as proof of concept. kko altered the installer js of the NoScript.xpi so that the script places the kmm at the right place. Before that I had found a good installer script for SeaMonkey inside NoScript and had made a kmm as caller macro for the NoScript configuration files.

Guess, at the momemnt the xpi installer service is only a toy for ppl that want to hack xpi.

The Problems - SeaMonkey xpi installer:
is less safe that Firefox xpi installer.
will not install firefox type extensions.
ppl will complain about "our" installer because:
Seamonkey extensions install but will not function without extra kmm
Firefox/Flock etc. extensions will not install at all

I understand why this service was not chosen as default installer service.
Like You I would have prefered it.



Edited 1 time(s). Last edit at 05/31/2007 05:14AM by guenter.

Quote
guenter

Quote
D555
I've haked .xpi too

good, did You find a usefull one?

Yes . I did it just to see the structure... . It's amazing - so much power in scripts - .js files ! It can do so much with Gecko API calls .
By example with DownThemAll! extension ...

I've been doing research on XPI for some time now, and I think I get how it works and how to make XPI's work with K-Meleon. Don't jump when you read this, it's A LOT OF WORK! Note I'll be referring to the new "Toolkit" method that Firefox and TBird currently use, because according to Mozilla, everything will be converted to Toolkit, and most people look at Firefox for extentions anyway, not Seamonkey.

What Makes an XPI
A ".xpi" file is just a glorified ".zip," you can view it's contents with any good archiving program. I am looking at one with 7-Zip while typing this. Every extension has an install.rdf file inside that provides display information and version compatability, which lists things like the included languages and any additional required items. The actual functionality and interface is found in the chrome folder in a ".jar" file. A ".jar" is again a standard archiving format and can be viewed with 7-Zip. In the ".jar" there should be a content folder. The content folder should have the program bits (*.js) and associated UI (*.xul) if applicable. Other important folders include locale for languages and skins for customizng the display.

What's Important for K-Meleon
There's a lot more that is usually found in an ".xpi" like XPCOM files and optional elements as well. However, what is important to K-Meleon is what needs to be solved to make XPIs work with K-Meleon. For those who don't know a lot about programming, to convert one language to another, we need to create a parser. While Javascript (the programming language of .XPIs) is a language that is easily run by any web browser, commands that mozilla use are specific to mozilla and K-Meleon couldn't understand them, especially in installing. There is the XPInstall API Reference that has a list of all the commands available for installation. Someone must "parse" the API so that XPI can simply be installed, though not run! A lot of work just here. However, do-able. I am not sure if the actual javascript that is found inside the chrome needs to be parsed, especially when it involves settings changes, but if they do, even more work. The last "basic" thing that needs to be done is parse the XUL API. There is currently an XUL parser for java that is not yet completed that may help in developing one that works for K-Meleon.

Summary
I hope this is accurate and helps clearify how complicated this would be. So, as far as I can see, the only way to have full support for an XPI is to create a XPInstall parser to understand how to copy the files, and at least an XUL parser to be able to display the appropriate GUI.

Links
Extension Packaging
Bundles - MDC
Install Manifests
Building An Extension
XPCOM
XPInstall API Reference
Parsing
XUL Parser Project

Bugzilla about "Suiterunner":

At 2007-05-11 09:43:39 PDT

Quote
Robert Kaiser
The SeaMonkey Council also agreed to switch the version number at the same time, so the point will be clearly marked and toolkit-based nightlies will be easy to distinguish from their precedessors.

Then at 2007-05-29 10:02:57 PDT

Quote
Robert Kaiser
Both patches have landed, along with clobbering our Dep tinderboxes, so we can
be sure only new code is picked up there now.

I hope everything goes well with that, so marking FIXED.

yay!

So called Trunk SeaMonkey 2.x = with Toolkit are build since 29/30.05.2007.

My guess: K-Meleon team knows this.

p. s. Up to now K-Meleon distros have rarely included activeX or xpi installer.
Both technologies have usability pros and security cons.

Even using the toolkit infra structure ( among it the FFox xpi installer ) will not give K-Meleon any use or any way to install Firefox XPI out of the box.
Contrary: The FFox installer service will securily prevent the install of any extensions not intended / made for K-Meleon by the creators of the extension!

K-Meleon does not become a XUL based application just by using FF-toolkit.
That is why I asked D555 whether he found anything (that might work for us).
We will still have to look for things to use or adapt for our use.



Edited 1 time(s). Last edit at 06/05/2007 11:42AM by guenter.

@simpleinventor:

XPIinstall is not the problem - not at all. Actually, it's pretty simple and it already works with K-Meleon. All the extensions Alain's providing at his site as NSIS installer packages, could also be installed as XPI packages!

The only problem is that the extensions written for Firefox/SeaMonkey don't integrate into K-Meleon's GUI due to the different menu/toolbar system. The method that is used to integrate an extension into the GUI of a XUL-based browser (chrome overlays), is - currently - not supported by K-Meleon. But there might be some chance that we can support Firefox overlays in future versions (we already thought about that). At the moment, all we had to do was to add additional macro modules (*.kmm) to a XPI in order to get menu entries or toolbar buttons added to K-Meleon which are added to Firefox/SeaMonkey through chrome overlays. But our macro extension was never meant to replace XUL - not all that's possible in XUL can be rebuild with macros.

@kko:

Can you find some links from Mozilla that go into Chrome Overlays? I really am unfamiliar with the concept. Also, where can I find out more on *.kmm? Can you explain the process of adding *.kmm a little further? I thought that since we don't want to use XUL, we needed to parse the XUL files using windows system calls. As you may have seen in a previous post of mine, there exists GUIs we can utilize. I think that new LUA maco system, coupled with a strong GUI can replace XUL.

Can you find some links from Mozilla that go into Chrome Overlays?

Look into the XUL section of the Mozilla Developer Center or XULPlanet's XUL Tutorial.


Can you explain the process of adding *.kmm a little further?

Well, you simply put your macro code in a *.kmm file instead of macros.cfg. These kmm files (macro modules) can then be placed in your macro folder or your user macro folder (see Edit > Configuration). My K-Meleon 1.x Reference may be beneficial to read.


I thought that since we don't want to use XUL, we needed to parse the XUL files using windows system calls.

I guess, you misunderstood something. We don't want to use XUL for our browser's user interface. But we can (or even want) use XUL for certain parts of the browser. The Advanced Preferences panel, the NewsFox feed reader and the Error Console (just to mention some) are all XUL applications. That has no negative impact on the browser's performance because these applications don't waste any resources when they're not running.


I think that new LUA maco system, coupled with a strong GUI can replace XUL.

I don't think so. Our aim is to make things easier for all involved (devs, translators, users). We want to make it easier for our macro coders to distribute their work and easier for our users to install such macros. That's why we have the kmm modules now. Similar to that, we should try to make it easier for the developers of Firefox add-ons to support k-meleon and easier for our users to install such add-ons. That's what the vast majority of our users is currently missing!

The LUA macro system isn't uninteresting, but to be honest, I don't really know where to put it. Obviously, it's more powerful than our current macro system and the LUA scripting language is wider spread than our macro language. But on the other hand, the km macro language is very simple (because it's only meant to solve simple problems) and thus also less experienced users can get into it. For more complicated things there are XUL applications. There are already hundreds of XUL applications. We only have to empower our users to use them. I mean, before we're going to 'replace' XUL applications by LUA applications (more or less replacing one scripting language by another), the following question should be answered first: Who will write all these LUA applications for k-meleon?
Ever thought about this?

Who will write all these LUA applications for k-meleon? Ever thought about this?

Yup, the automatic parser I was thinking of making

No matter who/what writes them - scripting languages are slower than native calls.
IMHO we want Lua funcions for what they can do well but like XUL not for things that
must be constantly parsed like user interfaces.

My imho .... ,basied on logical thinks .
Yes, native calls are faster of all, but really are hard by programming and packing for extensions... . XUL - easy and most possibilities can give ...BUT very SLOW....(very-very ).
BUT if lua and km macros real faster than XUL, and lua can give more possibility, why can't use lua ???
(And XUL no more simple that km macros, but there are exist a tons of extensions based on it).
So why lua can't be a golden mean ?



Edited 1 time(s). Last edit at 06/09/2007 05:14AM by D555.

guenter
How i can understood, KM is based on SeaMonkey structure...
May be became a time for FireFox structure in K-Meleon ?
(imho many problems in extensions installation and compatibility should be out...)

@KKO

Can you explain how *.kmm allow the use of Firefox plugins? Maybe some exampples with source code?

Edit > Configuration > Macros:

console2.kmm
kmprefs.kmm
mtypes.kmm
newsfox.kmm

@simpleinventor

+ all the extensions concerned by xul on my page

A+

---

Mozilla/5.0 (x11; U; Linux x86_64; fr-FR; rv:38.0) Gecko/20100101 Ubuntu/12.04 K-Meleon/76.0

---

Web: http://jujuland.pagesperso-orange.fr/
Mail : alain [dot] aupeix [at] wanadoo [dot] fr

---

Ubuntu 12.04 - Gramps 3.4.9 - Harbour 3.2.0 - Hwgui 2.20-3 - K-Meleon 76.0 rc

---

I managed to get the stylish extension working, well version 0.4 anyway, thanks to jk's excellent instructions here:

http://kmeleonbrowser.org/forum/read.php?1,70756,70969#msg-70969

works like a charm, except it seems to deactivate itself when the browser is closed, when you launch the browser the next time the extension doesn't seem to be applying styles anymore.

any ideas how to fix this? it would be a great extension to add to the now growing list.

I want some future ...
Possibility installation of .xpi(for example from FF site ..)
by that - FF extension must be placed in KM profile folder (like doing in FF)

And just put .kmm on place(or with place) of interface-.xul files

And want that it works fine just normal FF extensions.

(and in future - just use .kmm files on places of .xul files in .xpi modules. and install that modified modules liked usual .xpi modules)



Edited 1 time(s). Last edit at 06/15/2007 12:20PM by D555.

Quote
pencilneck
I managed to get the stylish extension working, well version 0.4 anyway, thanks to jk's excellent instructions here:

http://kmeleonbrowser.org/forum/read.php?1,70756,70969#msg-70969

works like a charm, except it seems to deactivate itself when the browser is closed, when you launch the browser the next time the extension doesn't seem to be applying styles anymore.

any ideas how to fix this? it would be a great extension to add to the now growing list.

Hey, in order to fix that you must delete these files:
compreg.dat
xpti.dat

They are in the KMeleon/Components directory. Once you restart K-Meleon those files will regenerate and everything will work.


I've packaged 0.4 and the newest ver., 0.5.2 here:
http://www.digivill.net/~joykillr/kmeleon/stylish_for_kmeleon.html

----------------------
- K-Meleon Macros and Extensions
- Greasify (Greasemonkey type macro for K-Meleon)
- Stylish for K-Meleon



Edited 1 time(s). Last edit at 09/13/2007 04:34AM by jk-.