General :
K-Meleon Web Browser Forum
No, just use it:
A new kmm version auto-choosing the html path style depending of the os
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
Edited 1 time(s). Last edit at 11/14/2014 04:57PM by JujuLand.
Attachments:
rvjMimeEdit0.6.1b.7z (38.9 KB)
You forgot to add any of Your changes in rvjmimeedit.txt. You added French locale, a great new macro and changed the position of the info file, mimeType.html ... ...
I did not sign my last change - so SVP do that for me when You update to the next version. Thank You in advance.
CHANGE LOG IMHO You edit above:
Version 0.6.1 K - 13 October 2014, Preview existing MIMETypes fixed, guenter.
p.s. If You use this: chrome://rvjmimeedit/content/mimeType.html for Windows
mimeType.html should IMHO be in ./content/ not in ./{fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/mimeType.html
Maybe that caused Your problem on Linux? Of old it used to be where You placed it.
But I found that it only can be called as chrome in content or content/pref.
Edited 3 time(s). Last edit at 11/15/2014 08:55AM by guenter.
Has I haven't tried under Windows, I just repeat what I found in you kmm :cool:
Isn't it what I write ?
No, I tried again these syntaxes:
I really think that wine isn't able to support such protocol, same as for resource://
[Edit]
I have remove the extension here, take it in the post I have uploaded today at 3:00 pm
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
Edited 1 time(s). Last edit at 11/15/2014 02:05PM by JujuLand.
I am always surprised that K-Meleon macros try to continue and do not stop like JS. And seem to give different results on other OS.
When I started to test Your macro in XP SP3, the error console said:
Sat Nov 15 2014 09:28:54
Error: : expected but found ,.
Source file: E:\K-Meleon74.0.16.10\macros\rvjmimeedit.kmm
Line: 24
Sat Nov 15 2014 09:28:54
Error: Invalid expression.,
,"file:///".getfolder(Roo
Source file: E:\K-Meleon74.0.16.10\macros\rvjmimeedit.kmm
Line: 24
Line 24 is:
ON XP SP3: These errors make that the URL about:addon from mtypes is used twice in setmenu (Line 37 and 38) since it is the last correct URL prevceding.
My macro knowledge is not sufficiant to fix the problem.
Best weekend to You
p.s. Is there a method to make a switch where the macro detects the OS or a feature typically present in Linux and the goes to the windows or the Linux macro?
I had posted this as change of my previous post. And You fixed and posted at the same time, je suis tres sorry.
Edited 1 time(s). Last edit at 11/15/2014 09:55AM by guenter.
Those complicated addon-extension paths are a complete mystery to me yet, so I had just kept the original paths you guys have posted.
Now came across this (VERY long) page about the structure of FF addons.
It contains also a chrome chapter, but no mention that chrome-paths wouldn't work under Linux.
Perhaps some path mistake in this mime-extension itself?
https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensions/XUL_School/The_Essentials_of_an_Extension
Sorry, there where two errors in the line I give for url type.
Here is the correct line
1) The separator between the two possible values was wrong: , instead of : ---------------------------------------------------------------------------------------- \/
2) I forget () around the test
----------- \/ ---------------------------------------------------------- \/
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
Attachments:
rvjMimeEdit0.6.2.7z (39.5 KB)
Here we try to make a Windows implementation of chrome:// to run under wine, and I suppose wine has not all the needed components to make it to 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
Still, the 7z by you and the one by guenter have a different folder structure.
This command cannot possibly work if the windows-line looks for the hmtl-page in the chrome-contents folder, and the linux-line looks for it in a parent folder of chrome. That has nothing to do if the link starts with chrome or with file, the subfolders don't match.
Please guys, make your mind up about where to place what ;-)
But I do suspect guenters structure may have better chances, since that Mozilla page also says the extension contents are meant to be placed in the contents folder...
1.) A total mystery to me also.
2.) Impossible.
That is an anciant part of the Mozilla/SeaMoney suite XUL code.
The addon code is far older than Firefox and older than K-Meleon.
Note that it goes one not needed step deeper to ./pref That is a Mozilla legacy.
chrome\rvjmimeedit.jar\content\pref\
The files originally housed in Mozilla in
\chrome\comm.jar\content\communicator\pref\
The code files bear the same old names and so on.
The basic code is not by a Bob Janc or a guenter but we merely altered it
to work with a new app and do the job after some other codes changed.
We are just among all Toms, Dicks and Harries that used and changed the code.
ACKNOWLEDGMENTS for K-Meleon
0 - All started with: Ben Goodger <ben@netscape.com> the original implementor of the Mozilla Code.
http://en.wikipedia.org/wiki/Ben_Goodger
What I think is possible that Linux uses rights more stringently.
So we may have to add something to its chrome.manifest.
content rvjmimeedit jar:rvjmimeedit.jar!/content/ contentaccessible=yes
3.) And yes copy the html to where it belongs.
chrome://rvjmimeedit/content/mimeType.html
So that alain does not have to upload again.
To do so: extract rvjmimeedit.jar here. Copy the file into content and add content to rvjmimeedit.jar as zip not 7z or other.
Edited 1 time(s). Last edit at 11/15/2014 04:34PM by guenter.
LOL! Okay, so let me rephrase it more precisely:
Perhaps some path mistake in those alterations? :cool:
That security stuff might well be another prob too, not just in Linux perhaps also in those ultramodern windows systems.
And you're funny, it wouldn't help a thing if *I* modify anything, since the next time one of you guys are posting it again all my own corrections are deleted again.
1.) Impossible.
2.) I changed content to accessible with the hope that it helps.
rvjmimeedit.manifest is now
content rvjmimeedit jar:rvjmimeedit.jar!/content/ contentaccessible=yes
locale rvjmimeedit en-US jar:rvjmimeedit.jar!/locale/en-US/
locale rvjmimeedit de jar:rvjmimeedit.jar!/locale/de-DE/
locale rvjmimeedit fr jar:rvjmimeedit.jar!/locale/fr-FR/
skin rvjmimeedit classic/1.0 jar:chrome/rvjmimeedit.jar!/skin/
Relocated the mimeTypes.html to
./chrome/rvjmimeedit.jar/content/pref/mimeTypes.html.
And changed the macro. We have 3 Items now. Addon Manager, Edit mimeTypes.rdf and MIMETypes Info. Replaced all "mtypes" strings.
Updated changelog so that we know who committed what recent change.
To do: find out why original mtypes.kmm still does not work side by side.
Test under Linux whether macro works there too now.
Create package again. Some one that does not have constant 503 or similar.
CHANGE LOG
Edited 1 time(s). Last edit at 11/15/2014 05:29PM by guenter.
You can remove me from the history, since it doesn't contain any contributions by me. And even if there were a line, that would be peanuts not worth mentioning considering it would be 0.0x % of that whole extension.
What I still keep riddling, what's your "modified version of main.kmm" thing about? Some trick requiring frames?
(sorry am lazy too and too bothersome to get the offline machine out of the closet ;-P)
PS: please do occasionally a quick test of your published macros. Mistakes happen, but for the x-th time the menus are still mixed up, although you even had noticed it meanwhile
PS2: What do you mean with that?
I hope you don't mean that both extensions shall run at the same time, because you keep disabling that fully intentionally.
PS3 ;-)
And is there some automatism now that every 74 extension gets an own window pref by KM? Because I cannot find the definition in this package.
Edited 2 time(s). Last edit at 11/15/2014 06:00PM by siria.
1.) Denied. You became part of the crime/cabale when You posted a macro which was used to improve the next version.
2.) No, that is alains idea. I play with a clean new install for such work.
3. PS.) JamesD wrote something along that line. Forum changes macros a little at times.
Go Quote and then use the text inside code tags code -> /code You know.
That should work.
4.PS2.) Can You explain why the macros are not working side by side with data in mimeTypes.rtf getting precedence?
5.PS3.) I used code to make sure that the MIMETypes editor component gets a window no tab.
It must be a moveable window that can be dragged before the info page.
Damit man abschreiben und spieken kann.
For the rest. You and alain are the code gurus. I am just a user - with eleven years experience in end user support. 8000+ plus posts - mostly idle chatting.
That gives me a big history: in trial and error.
I already know how others fixed some problems - or what ways to try.
Serious. alain code does something that I do not comprehend.
So I moved my macro commands into a position/order that works in XP SP3.
I knew that this reordering might help somtimes.
I tested my code snippet at different positions in the macro till all worked
A mere workaround until You code guru guys' fix it because You know the reason.
p.s. I'd never fix anything that works. I am lazzy and do not care why.
Hope I understood Your post.
Der neue Code ist langsamer als meiner für Win OS.
Edited 1 time(s). Last edit at 11/15/2014 07:18PM by guenter.
Hi, guenter and Siria,
what goes wrong with the kmm I send ?
The os test ?
It works in mail.kmm that you have on your computer ...
$tux is a global variable created in main.kmm.
So, $URL for Linux works ok. does $URL for Windows fail ?
I really don't understand.where is the problem ...
Siria, here is the modified main.kmm which allows to have functions like about, ... to be opened in a new tab instead of a new window (but which also allows new window. Now we have the choice ...
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
Edited 2 time(s). Last edit at 11/15/2014 08:50PM by JujuLand.
Attachments:
main.kmm (33.8 KB)
Yes that attachment contains the main.kmm modifications that were introduced in KM1.6, guess by desga in a later beta version but not sure anymore. And then Dorian dropped them again because he reinvented the wheel and based KM74 on KM1.5.4 again. Or was it the first beta?
Anyway, the point is, I understand what it does, it's very clear from its code and very simple. But those modifications in main.kmm have absolutely nothing to do with this mimetypes macro and the hidden lines in it. There is no relation, with or without those ominious hidden lines. Main.kmm does not determine what other macros do. And why frames?
The whole "secret" whether a page is opened in a new tab or in a new window is simply this:
Define the URL with
$OpenURL="...."
then fire
&OpenURL_InNewWindow = opens a new window
&OpenURL_InNew = opens a new tab if tabs plugin is enabled, otherwise a new window
That's not exactly "guru" stuff guenter! Even you can do that, after ten years of user support with 8000+ postings :cool:
Edited 4 time(s). Last edit at 11/15/2014 09:16PM by siria.
ok, but if someone wants to change this behavior, he must change the macro, else just a pref, which can be done if Dorian accept to reintroduce it, with a included macro or in kmprefs.
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
Edited 1 time(s). Last edit at 11/15/2014 09:19PM by JujuLand.
@guenter
This line don't work, and I haven't tried to use file:// for xul
chrome://rvjmimeedit/content/pref/pref.xul
works. So we can simplify it, but the size isn't ok, the box takes all the window.
What is trash ... using about:addons, does not have this problem ...
Is it ok with Windows ?
For mimetype.html, I confirm that chrome://rvjmimeedit/content/pref/mimeType.html doesn't work ...
It seems that chrome:// is just accepted for xul, not html ...
[Edit]
I have now saw that I forgot to put html file in jar file, so chrome:// works :mad:
openinNew is ok ...
For xul, as I my first test gives a trash display, I tried reducing K-Meleon (not maximized), and the mimetype window had a correct size. Now maximizing K-Meleon, after restart, I don't have anymore that trash display.
I don't understand ...
I found a pref :
user_pref("extensions.rvjmimeedit.openinwindow", false);
I don't write, and it won't can explain it. Removing it, it works always correctly ???
so we can simplify it.
I'll post a new one tomorrow
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
Edited 2 time(s). Last edit at 11/15/2014 10:00PM by JujuLand.
Of course the mime-html can't work with your jar, because you keep that file in the chrome parent folder instead of the chrome content pref folder. Move it there and try again?
The way your macro is build, he must edit your macro too and unhide those lines. And then there's the prob, that your extension doesn't create this openinwindow-pref anywhere, at least I can't find it? And of course no GUI for the user either to toggle it. If he doesn't study the code carefully he'll never even guess this possibility exists.
Considering this it doesn't seem much harder for him to change "...InNewWindow" into "...InNew" in the kmm.
No idea what Dorian would have to do with that pref, it's clearly an extension-specific pref, not a global one.
Hope I understood all.
1.) I always work with an unaltered K-Meleon for such things.
What are You telling me about what main.kmm I use?
The official nothing else. Because it must later work with it.
2.) You are right, that's not exactly "guru" stuff, alain!
It IMHO forces to open a new XUL window with the default size that I gave in one of the dtd.
And I know that You know that too because You did the French translation during all the years.
Translators know about size in dtd.
If we give users that choice You seem to want to give - some are bound to complain.
The macro opens the pref.xul at a size that is similar/comparable to the size that is opened forcibly by the Firefox style Addon Manager. So I guess there might be a reason for it.
But that is not my real reason. So let me explain my idea.
I choose chrome://rvjmimeedit/content/pref/pref.xul plus &OpenURL_InNewWindow because if we go via about:addons we cannot switch or drag so easy to/before chrome://rvjmimeedit/content/mimeType.html.
Only when &OpenURL_InNewWindow and pref.xul is used directly You can IMHO always drag the xul window before the html info page while You are editing. And the XUL window must not fill the whole page. No matter what open window/tab setting the user has as default preference.
That was my idea and concept.
That is why I wrote as comment into the kmm:
So &OpenURL_InNewWindow is by my design. I do not want the user to have any choice for a practical reason.
Else I may generate a FAQ.
How can I drag the editor before the info page?
And I sure do not want to answer that.
p.s. Some XUL pages remember what size etc. they had last. Mozilla XUL feature. IMHO Pref.xul we use has it. https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/persist
That is stored somewhere. If I remember right in an rdf.
Edited 2 time(s). Last edit at 11/16/2014 05:27AM by guenter.
In my imagination, a guru has a long beard and lives alone in the high mountains and down from time to time in the plain to find his fervent followers ...
I do not have the beard for a long time, I am not alone, I live full time in the plains and have not yet met followers. So even if I could caress hope, I could never call myself guru.
Have I argued, first?
I'll post a simplified version.
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
Here is the last version with all the needed files updated.
Tell me if it's ok.
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
Attachments:
rvjMimeEdit0.6.3.7z (40.6 KB)
Technically Ok.
Much better. Almost matches again mine and guenters cleaned up version on the first page :cool:
Except one important point that's still missing. So, since we still can't find an agreement about allowing the native editor too, I finally decided to give in and create a "fork" macro.
Did some testing now, just trial-and-error, and to my pleasant surprise found that KM1.6 can run RJV too!
Even much easier than KM74, all KM1.6 needs is to have rvjmimeedit.jar + manifest in the KM/chrome folder
For our macros the KM version doesn't matter anyway, since they are only about menu building, and thanks to the special chrome-links the editor-paths are the same in all versions.
The result of that testing was that both editors are really needed parallel, because each one is missing a function that only the other one can. Unless that's only in KM1.6, but have doubts that in KM74 the editors work any different - or do they??
So if anyone wants both editors at the same time, install rvjmimeedit.7z from above in KM74 (in older KM versions extract only rvjmimeedit.jar + manifest and put them into the KM/chrome folder). Then add this alternative menu macro:
copy the text below into a new notepad document, and save it as "MimeEditRVJ.kmm" (with option "all files") into a KM/macros folder:
#----------
#UTF-8 K-Meleon Macros (http://kmeleon.sourceforge.net/wiki/index.php?id=MacroLanguage2)
#
# ---------- MimeEditRVJ menu macro (for MIME Type Editors)
#
# Version: 1.0 / 2014-11-16 / by siria (FORK of rvjmimeedit-macro by jujuland+guenter)
# Forum: kmeleonbrowser.org/forum/read.php?1,130230
# Menu: Edit > MIME Types
# Dependencies KM74 : xul addon "rvjmimeedit" (several files+folders / the menu macro (kmm) can be disabled)
# Dependencies KM1.6 : rvjmimeedit.jar + manifest in folder K-Meleon/chrome
# (Tested only in KM1.6 yet)
#
# This is only a menu macro. It uses two mime type editors parallel, the native mtypes-editor
# and the alternative RVJ-editor. RVJ can create NEW mime types, which the native one can not.
# RVJ also allows to define the "always ask" function for single types.
# But the native editor can edit AUTO-mime types, the RVJ-editor only manual types.
# This macro creates a menu to open BOTH editors, depending on which function you need.
# ----------------------------------------------------------------------------
MimeEditRVJ_typesInfo{
macroinfo=_("MIME Types list for information");
$OpenURL="chrome://rvjmimeedit/content/pref/mimeType.html";
&OpenURL_InNew;
}
MimeEditRVJ_edit{
macroinfo=_("Change file type settings (MIME Types) with RVJ-editor");
$OpenURL="chrome://rvjmimeedit/content/pref/pref.xul";
&OpenURL_InNewWindow;
}
MimeEditRVJ_new{
macroinfo=_("Add new file type (MIME Type), open with info list");
&MimeEditRVJ_typesInfo;
&MimeEditRVJ_edit;
}
#---------- Fallback workaround
# if native mtypes-macro was disabled or if rvjmimeedit-macro is active, which conflicts with it:
MimeEditRVJ_mtypes{
macroinfo=_("Change file type settings");
$OpenURL="chrome://kmprefs/content/pref-filetypes.xul";
# $OpenURL="chrome://kmprefs/content/pref.xul?filetypes";
&OpenURL_InNewWindow;
}
_MimeEditRVJ_checkNative{
if (index($macroModules,";rvjmimeedit;") > -1)
setmenu("Preferences",macro,"MIME T&ypes (KM editor)",MimeEditRVJ_mtypes,"MIME T&ypes...");
else
index($macroModules,";mtypes;") > -1 ? 0 : setmenu("Preferences",macro,"MIME T&ypes...",MimeEditRVJ_mtypes,-1);
}
#---------------
_MimeEditRVJ_BuildMenu{
&_MimeEditRVJ_checkNative;
setmenu("Preferences",macro,"MIME Types (RVJ+InfoPage)","MimeEditRVJ_new","MIME T&ypes...");
setmenu("Preferences",macro,"MIME Types (RVJ-Editor)","MimeEditRVJ_edit","MIME T&ypes...");
### setmenu("Preferences",macro,"MIME Types Info List","MimeEditRVJ_typesInfo","MIME T&ypes...");
}
#------------------
$OnInit=$OnInit."_MimeEditRVJ_BuildMenu;";
$macroModules=$macroModules."MimeEditRVJ;";
Edited 2 time(s). Last edit at 11/17/2014 12:47AM by siria.
Thank You for the macro siria.
siria the reason is IMHO in the XUL code. Both items called by the two macros have the name "pref.xul" and the same "ID". IMHO that is the deeper reason. Since Your macro works around this problem You have found this out too.
There are several other things to do also. Some things that I can do and some that I cannot. So I did not start at all. Change options URL and code name and ID that belongs to it, add icon, new ID (number belongs to Bob Janc - there should not be two add-ons with the same ID and the same name for the addon), clean code inside jar, add homepage to install.rdf (this thread), add icon location to install.rdf... and finally we need a solution so that the kmm can be inside the add-on so that it can be removed with the addon.
And possibly in the macro code of alain who re-used the string "mtypes".
In my macro I had avoided using the same string again.
Nice to know that I could use this version for 1.6 too.
Edited 2 time(s). Last edit at 11/17/2014 05:43AM by guenter.
No, sorry, can't be. Or do you see anything in my macro code that would modify the name of those xul files or their IDs??
The truth is much simpler: both our *KMM* macros create only menu lines, and those only call a url, nothing else.
Creating menus doesn't modify any xul or other files. So disabling the native macro (kmm), what the latest 7z package does, only removes the native menu lines, not modifies their called target pages (url). The 7z package disables this native menu via a global default pref and uses conflicting identical macro-commandnames.
Perhaps the other (non-kmm) files in the 7z may manipulate the native xul too in some way? Since I have not copied over the other files, this doesn't happen in my old KM anyway. My own little kmm sure doesn't modify any xul files, just take a quick look inside.
But as for the other files, you could do a simple test in your original KM74 installation? If you add only the latest extension (not my kmm), then restart KM and call F2>FileHandling>By Type: Does this pref tab still use the native editor (without "add new" button), or is it replaced with the RVJ-editor??
If still native, then you can use both editors parallel without needing my changed kmm at all. Then both xul's are still both active at the same time. Despite the hidden native menu. A user just has to know that alternative entry point first.
A kmm is very easy to remove or disable, it's an additional file, and it's the known default location to extend KM. So users can disable kmm's in the pref sheets or even just delete the files. But the other files that addons like this create outside the add-on itself are far more difficult to remove, and even to figure out! Like the overwritten default sheets for filetypes, and the files creating other default prefs etc. Removing those and replacing again with the original ones is far harder for a clueless user. So please leave the kmm in the macros folder for now, it's far more important to move the other files inside the add-on.
Edited 1 time(s). Last edit at 11/17/2014 10:00AM by siria.
As mentioned, my macro doesn't touch those and the editors still work fine (in KM1.6), but since you use more files for KM74, rdf etc., who knows what those do.
But why don't you simply rename the stuff you suspect and then look if the behaviour changes in any way? Trial and error, and only practical tests will show the truth.
Also if the homepage is nothing but a tag in rdf (is it?), why not simply look how other extensions add their homepages and then just try adding it the same way? If that avoids potential conflicts it would be worth at least trying, why not?
You IMHO knew why You used pref-filetypes.xul instead of pref.xul in Your macro.
So do I. That elegantly avoided the problem, same name, same ID.
So You also think the string "mtypes" is conflicting. I was not sure.
I know what I have to change in the install.rdf. That is trivial.
My problem is that I hesitate to start when I do not know all. Which I don't.
Your splendid macro makes the two XUL extensions/prefs work side by side.
So why should I tinker with the addon before kmm can be in addons?
disrupted made the extension manager because normal users have problems with removing items likes macros etc. from their folders.
p.s. Ich hab schon was geändert, weiß aber nicht, ob ich alles mache und wann.
Du brauchst unter 1.6 nur <dialog id="options" statt <dialog id="prefDialog"
in pref.xul eintragen und die Datei in options.xul umbenennen. Es gibt vermutl. noch 1000 andere Möglichkeiten. In den Macros diese Änderung eintragen, die störenden mtypes in rvjmimeedit.kmm ändern, und los gehts. Für 74 ist es etwas - aber kaum mehr. 3 Coder 3 Wege. Oder mehr? Lach.
Dein Macro ist eine Wucht. Besonders wo du zwei Fenster gleichzeitig öffnest!
Edited 3 time(s). Last edit at 11/17/2014 07:49PM by guenter.
LOL! Yes I know why, but you're assuming wrong again
You still cling to your deep conviction that it must be something "complicated", but really, the name of the link targets don't make any problems (they ARE different before the ending), at least not in my KM1.6.
All 3 xul-editor links work perfectly, have tested it! (you could test too, but don't seem to bother)
The only reason I chose the other page is that as a side-effect the visible layout difference tells me whether the native mtypes is active OR the rvjmimeedit-macro. Just for curiosity!
The native one can coexist peacefully with all other macros that follow kko's macro guidelines, but rvjmimeedit comes 1) with a default pref that disables it intentionally, even in new profiles and 2) also with a conflicting command name "macros(mtypes)".
Why do you find it so difficult to understand that it *cannot* possibly work to call one editor with the command "macros(mtypes)" and then another editor with exactly the same command "macros(mtypes)"?
Look inside native mtypes.kmm, perhaps you understand better then (it's just a tiny 1-link-macro). I had mentioned in one of my first replies already that the same name gives conflicts, later I rewrote the macro myself and changed the conflicting name, you added more improvements, it did work fine parallel at that time already. Alain didn't want any of it and changed all back, a bit later yourself changed the conflicting name again, and again he insisted to change it back, and also added the pref to automatically disable mtypes.kmm. Is it really such a wonder that those two macros don't work parallel that way?
Therefore, if rvjmimeedit is among the active macros, mine must restore the link to the native editor again, otherwise not. So just because I'm curious, to see if the current link was created by the native macro or by my copy of it, I chose to use a slightly different editor link. Which looks exactly the same anyway, just without sidebar. If you don't want to know which macro created the current menu, you can just as well use the pref.xul link again. That's exactly why both links are still included.
But hey - you can very easily demonstrate to yourself if parallel use is possible or not: Just open the native editor! If the menu link was disabled, open it via F2>FileTypes. The layout and (missing) buttons show which one it is.
Another indicator: if you put a new, nearly empty DEFAULT mimeTypes.rdf in the current profile (as it was before overwritten with the rvj-template), then even the content is different: the native editor shows also the automatic plugin entries, RVJ not, it can't see those. At least when I test it, but there are no other testers around. Your huge list is handy of course, just for testing such differences a bit too long.
siria, ich habe mtypes kmm mal gemacht - na ja, ne noch ältere Version geändert.:O
Egal. Ich bin mit meinem Ding fertig. Danke für deinen Makro Beitrag.
Werde mal in einer stillen Stunde hoch laden.
p.s. Das einzige was ich noch gern wissen will - wie tut man die kmm in das Add-on.
Das hatte Dorian ja mal getan.
Hier ist mein Makro schon mal. Ich glaube du verwechselst alains mit meinen kmm.
Edited 1 time(s). Last edit at 11/17/2014 10:33PM by guenter.
Oh, yet another... hmm... let me guess, it's just a renamed copy of rvj-editor? Or not?
But please, do a little **TEST** before publishing the final version. You guys never seem to test your own stuff! As this thread has shown again and again and again, and I don't get it...
While I see already at first look another little menu glitch.... but I leave the discovery to your test, it's really extremely easy :-P
But how about finally starting a little crash course in macro writing? :cool:
(I know little people bother to stick to it, but still kko's guidelines make a lot of sense and reduce conflicts):
Especially the lines about naming conventions for macro names (the single command blocks inside the kmms)...
http://kmeleon.sourceforge.net/wiki/MacroGuidelines
And kko also recommends:
Not to be too nitpicky, but if this is about to get a final publish, the typos in the mime-list could get corrected. Just a global text replacement for "extention" -> "extension", takes only a few seconds.
Whether about:addons belongs in a mimetypes macro may be a matter of opinions. Why I finally had removed it was the thought, that this command should really be a native one by Dorian, and hopefully soon, and then it would be double. And also my impression had been that in the beginning it only was used in the mimetypes-macro because the direct pref.xul path didn't work yet (which obviously turned out wrong), and now it's not necessary any more for a pure mimetypes macro.
And the header is IMO still lying if it claims that no other files of any kind were needed for this extension to work, only this link macro. Makes it much more difficult for users to figure out the rest of the files.
Okay, genug gemeckert ;-) Nur eins noch, bitte den mtypes-killer pref in der js noch rausmachen?
Ah.. doch noch was vergessen: Platzier das Menü wieder direkt über dem originalen, die zusammengehörenden mime-Zeilen brauchen ja nicht sinnlos verstreut werden (s. Ende von setmenu)
Edited 2 time(s). Last edit at 11/17/2014 11:46PM by siria.
General discussion about K-Meleon
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
JujuLand
Date: November 14, 2014 04:42PM
Quote
guenter
Then we must have two macros.
No, just use it:
$OpenURL=$tux==""?"chrome://rvjmimeedit/content/mimeType.html",
"file:///".getfolder(RootFolder)."/browser/extensions/{fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/mimetype.html";
A new kmm version auto-choosing the html path style depending of the os
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
Edited 1 time(s). Last edit at 11/14/2014 04:57PM by JujuLand.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 14, 2014 08:03PM
Quote
JujuLand
Quote
guenter
Then we must have two macros.
No, just use it:
You forgot to add any of Your changes in rvjmimeedit.txt. You added French locale, a great new macro and changed the position of the info file, mimeType.html ... ...
I did not sign my last change - so SVP do that for me when You update to the next version. Thank You in advance.
CHANGE LOG IMHO You edit above:
Version 0.6.1 K - 13 October 2014, Preview existing MIMETypes fixed, guenter.
p.s. If You use this: chrome://rvjmimeedit/content/mimeType.html for Windows
mimeType.html should IMHO be in ./content/ not in ./{fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/mimeType.html
Maybe that caused Your problem on Linux? Of old it used to be where You placed it.
But I found that it only can be called as chrome in content or content/pref.
Edited 3 time(s). Last edit at 11/15/2014 08:55AM by guenter.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
JujuLand
Date: November 15, 2014 08:32AM
doneQuote
guenter
You forgot to add any of Your changes in rvjmimeedit.txt. You added French locale, a great new macro and changed the position of the info file, mimeType.html ...
I did not sign my last change - so SVP do that for me when You update to the next version. Thank You in advance.
CHANGE LOG IMHO You edit above:
Version 0.6.1 K - 13 October 2014, Preview existing MIMETypes fixed, guenter.
Quote
guenter
p.s. If You use this: chrome://rvjmimeedit/content/mimeType.html for Windows
mimeType.html should IMHO be in ./content/ not in ./{fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/mimeType.html
Has I haven't tried under Windows, I just repeat what I found in you kmm :cool:
Isn't it what I write ?
Quote
guenter
Maybe that caused Your problem on Linux? Of old it used to be where You placed it.
But I found that it only can be called as chrome in content or content/pref/
No, I tried again these syntaxes:
chrome://content/pref/mimeType.html chrome://content/mimeType.htmland it fails
I really think that wine isn't able to support such protocol, same as for resource://
[Edit]
I have remove the extension here, take it in the post I have uploaded today at 3:00 pm
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
Edited 1 time(s). Last edit at 11/15/2014 02:05PM by JujuLand.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 15, 2014 09:00AM
I am always surprised that K-Meleon macros try to continue and do not stop like JS. And seem to give different results on other OS.
When I started to test Your macro in XP SP3, the error console said:
Sat Nov 15 2014 09:28:54
Error: : expected but found ,.
Source file: E:\K-Meleon74.0.16.10\macros\rvjmimeedit.kmm
Line: 24
Sat Nov 15 2014 09:28:54
Error: Invalid expression.,
,"file:///".getfolder(Roo
Source file: E:\K-Meleon74.0.16.10\macros\rvjmimeedit.kmm
Line: 24
Line 24 is:
$OpenURL=$tux==""?"chrome://rvjmimeedit/content/mimeType.html","file:///".getfolder(RootFolder)."/browser/extensions/{fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/mimetype.html"
ON XP SP3: These errors make that the URL about:addon from mtypes is used twice in setmenu (Line 37 and 38) since it is the last correct URL prevceding.
My macro knowledge is not sufficiant to fix the problem.
Best weekend to You
p.s. Is there a method to make a switch where the macro detects the OS or a feature typically present in Linux and the goes to the windows or the Linux macro?
I had posted this as change of my previous post. And You fixed and posted at the same time, je suis tres sorry.
Edited 1 time(s). Last edit at 11/15/2014 09:55AM by guenter.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 15, 2014 12:05PM
Those complicated addon-extension paths are a complete mystery to me yet, so I had just kept the original paths you guys have posted.
Now came across this (VERY long) page about the structure of FF addons.
It contains also a chrome chapter, but no mention that chrome-paths wouldn't work under Linux.
Perhaps some path mistake in this mime-extension itself?
https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensions/XUL_School/The_Essentials_of_an_Extension
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
JujuLand
Date: November 15, 2014 02:02PM
Sorry, there where two errors in the line I give for url type.
Here is the correct line
1) The separator between the two possible values was wrong: , instead of : ---------------------------------------------------------------------------------------- \/
2) I forget () around the test
----------- \/ ---------------------------------------------------------- \/
$OpenURL=($tux==""?"chrome://rvjmimeedit/content/mimeType.html" :
"file:///".getfolder(RootFolder)."/browser/extensions/
{fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/mimetype.html");
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
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
JujuLand
Date: November 15, 2014 02:10PM
I agree with you, but don't forget that it's talking about Linux Firefox version running under Linux.Quote
Siria
It contains also a chrome chapter, but no mention that chrome-paths wouldn't work under Linux.
Perhaps some path mistake in this mime-extension itself?
Here we try to make a Windows implementation of chrome:// to run under wine, and I suppose wine has not all the needed components to make it to 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
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 15, 2014 02:58PM
Quote
JujuLand$OpenURL=($tux==""?"chrome://rvjmimeedit/content/mimeType.html" : "file:///".getfolder(RootFolder)."/browser/extensions/ {fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/mimetype.html");
Still, the 7z by you and the one by guenter have a different folder structure.
This command cannot possibly work if the windows-line looks for the hmtl-page in the chrome-contents folder, and the linux-line looks for it in a parent folder of chrome. That has nothing to do if the link starts with chrome or with file, the subfolders don't match.
Please guys, make your mind up about where to place what ;-)
But I do suspect guenters structure may have better chances, since that Mozilla page also says the extension contents are meant to be placed in the contents folder...
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 15, 2014 03:30PM
Quote
siria
Those complicated addon-extension paths are a complete mystery to me yet, so I had just kept the original paths you guys have posted.
snip...
Perhaps some path mistake in this mime-extension itself?
snip...
Still, the 7z by you and the one by guenter have a different folder structure.
1.) A total mystery to me also.
2.) Impossible.
That is an anciant part of the Mozilla/SeaMoney suite XUL code.
The addon code is far older than Firefox and older than K-Meleon.
Note that it goes one not needed step deeper to ./pref That is a Mozilla legacy.
chrome\rvjmimeedit.jar\content\pref\
The files originally housed in Mozilla in
\chrome\comm.jar\content\communicator\pref\
The code files bear the same old names and so on.
The basic code is not by a Bob Janc or a guenter but we merely altered it
to work with a new app and do the job after some other codes changed.
We are just among all Toms, Dicks and Harries that used and changed the code.
ACKNOWLEDGMENTS for K-Meleon
0 - All started with: Ben Goodger <ben@netscape.com> the original implementor of the Mozilla Code.
http://en.wikipedia.org/wiki/Ben_Goodger
What I think is possible that Linux uses rights more stringently.
So we may have to add something to its chrome.manifest.
content rvjmimeedit jar:rvjmimeedit.jar!/content/ contentaccessible=yes
3.) And yes copy the html to where it belongs.
chrome://rvjmimeedit/content/mimeType.html
So that alain does not have to upload again.
To do so: extract rvjmimeedit.jar here. Copy the file into content and add content to rvjmimeedit.jar as zip not 7z or other.
Edited 1 time(s). Last edit at 11/15/2014 04:34PM by guenter.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 15, 2014 03:50PM
Quote
guenterQuote
siria
Perhaps some path mistake in this mime-extension itself?
2.) Impossible.
That is an anciant part of the Mozilla/SeaMoney suite XUL code.
....
The basic code is not by a Bob Janc or a guenter but we just altered it
to work with a new app and do the job after some other codes changed.
LOL! Okay, so let me rephrase it more precisely:
Perhaps some path mistake in those alterations? :cool:
That security stuff might well be another prob too, not just in Linux perhaps also in those ultramodern windows systems.
And you're funny, it wouldn't help a thing if *I* modify anything, since the next time one of you guys are posting it again all my own corrections are deleted again.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 15, 2014 05:26PM
Quote
siria
Quote
guenterQuote
siria
Perhaps some path mistake in this mime-extension itself?
2.) Impossible.
That is an anciant part of the Mozilla/SeaMoney suite XUL code.
Perhaps some path mistake in those alterations? :cool:
That security stuff might well be another prob too, not just in Linux perhaps also in those ultramodern windows systems.
1.) Impossible.
2.) I changed content to accessible with the hope that it helps.
rvjmimeedit.manifest is now
content rvjmimeedit jar:rvjmimeedit.jar!/content/ contentaccessible=yes
locale rvjmimeedit en-US jar:rvjmimeedit.jar!/locale/en-US/
locale rvjmimeedit de jar:rvjmimeedit.jar!/locale/de-DE/
locale rvjmimeedit fr jar:rvjmimeedit.jar!/locale/fr-FR/
skin rvjmimeedit classic/1.0 jar:chrome/rvjmimeedit.jar!/skin/
Relocated the mimeTypes.html to
./chrome/rvjmimeedit.jar/content/pref/mimeTypes.html.
And changed the macro. We have 3 Items now. Addon Manager, Edit mimeTypes.rdf and MIMETypes Info. Replaced all "mtypes" strings.
Updated changelog so that we know who committed what recent change.
To do: find out why original mtypes.kmm still does not work side by side.
Test under Linux whether macro works there too now.
Create package again. Some one that does not have constant 503 or similar.
CHANGE LOG
Version 0.6.2 - 15 November 2014, by alain, siria and guenter : bugfix, Kmm modified, mimeType.html relocatet to .contentr/pref, guenter. Version 0.6.2 - 14 November 2014, by guenter, siria and alain : kmm modified and prefs added to make it avalaible immediately when installed, alain. Version 0.6.1 K - 13 October 2014, by guenter
# K-Meleon Macros (http://kmeleon.sourceforge.net/wiki/index.php?id=MacroLanguage)
# ---------- rvjmimeedit Extension (MIME Type Editor) -------------------------------------------------------------------
#
# Dependencies : main.kmm (OpenURL)
# Resources : -
# Preferences : -
# Warning : to use it, don't forget to uncheck mtypes.kmm in preferences
# no more needed, as install disable it
# ------------------------------------------------------------------------------------------------------------------
# We always want this as separarate Window so that we can drag it before an open mimeType.html
minetypes{
macroinfo=_("Edit mimeTypes.rdf");
$OpenURL=($tux==""?"chrome://rvjmimeedit/content/pref/pref.xul":"file:///".getfolder(RootFolder)."/browser/extensions/{fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/chrome://rvjmimeedit/content/pref/pref.xul"); &OpenURL_InNewWindow;
mytypes{
macroinfo=_("Addon Manger");
$OpenURL="about:addons";
# In case you have a modified version of main.kmm which allows to open About items in new tab instead
# of new window. Just comment the first line to come, and uncomment the next one
&OpenURL_InNewWindow;
#setpref(BOOL,"extensions.rvjmimeedit.openinwindow")==true ? $ExecMacros="OpenURL_InNewWindow":$ExecMacros="OpenURL_InNew";&ExecMacros_Frames;
}
mimetypes{
macroinfo=_("MimeTypes Information");
$OpenURL=($tux==""?"chrome://rvjmimeedit/content/pref/mimeType.html":"file:///".getfolder(RootFolder)."/browser/extensions/{fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/chrome://rvjmimeedit/content/pref/mimeType.html");
# In case you have a modified version of main.kmm which allows to open About items in new tab instead
# of new window. Just comment the first line to come, and uncomment the next one
&OpenURL_InNew;
#getpref(BOOL,"extensions.rvjmimeedit.openinwindow")==true ? $ExecMacros="OpenURL_InNewWindow":$ExecMacros="OpenURL_InNew";&ExecMacros_Frames;
}
# ----- PRIVATE
_mytypes_BuildMenu{
# edit menu
setmenu(KMAbout,macro,_("Edit mimeTypes.rdf"),minetypes);
setmenu(KMAbout,macro,_("MIME T&ypes Info"),mimetypes);
setmenu(Preferences,macro,_("Addon Manager"),mytypes);
}
$OnInit=$OnInit."_mytypes_BuildMenu;";
# ------------------------------------------------------------------------------------------------------------------
$macroModules=$macroModules."rvjmimeedit;";
Edited 1 time(s). Last edit at 11/15/2014 05:29PM by guenter.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 15, 2014 05:50PM
You can remove me from the history, since it doesn't contain any contributions by me. And even if there were a line, that would be peanuts not worth mentioning considering it would be 0.0x % of that whole extension.
What I still keep riddling, what's your "modified version of main.kmm" thing about? Some trick requiring frames?
(sorry am lazy too and too bothersome to get the offline machine out of the closet ;-P)
PS: please do occasionally a quick test of your published macros. Mistakes happen, but for the x-th time the menus are still mixed up, although you even had noticed it meanwhile
PS2: What do you mean with that?
Quote
guenter
To do: find out why original mtypes.kmm still does not work side by side.
I hope you don't mean that both extensions shall run at the same time, because you keep disabling that fully intentionally.
PS3 ;-)
And is there some automatism now that every 74 extension gets an own window pref by KM? Because I cannot find the definition in this package.
Edited 2 time(s). Last edit at 11/15/2014 06:00PM by siria.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 15, 2014 07:07PM
Quote
siria
You can remove me from the history, since it doesn't contain any contributions by me. And even if there were a line, that would be peanuts not worth mentioning considering it would be 0.0x % of that whole extension.
What I still keep riddling, what's your "modified version of main.kmm" thing about? Some trick requiring frames?
(sorry am lazy too and too bothersome to get the offline machine out of the closet ;-P)
PS: please do occasionally a quick test of your published macros. Mistakes happen, but for the x-th time the menus are still mixed up, although you even had noticed it meanwhile
PS2: What do you mean with that?
Quote
guenter
To do: find out why original mtypes.kmm still does not work side by side.
I hope you don't mean that both extensions shall run at the same time, because you keep disabling that fully intentionally.
PS3 ;-)
And is there some automatism now that every 74 extension gets an own window pref by KM? Because I cannot find the definition in this package.
1.) Denied. You became part of the crime/cabale when You posted a macro which was used to improve the next version.
2.) No, that is alains idea. I play with a clean new install for such work.
3. PS.) JamesD wrote something along that line. Forum changes macros a little at times.
Go Quote and then use the text inside code tags code -> /code You know.
That should work.
4.PS2.) Can You explain why the macros are not working side by side with data in mimeTypes.rtf getting precedence?
5.PS3.) I used code to make sure that the MIMETypes editor component gets a window no tab.
It must be a moveable window that can be dragged before the info page.
Damit man abschreiben und spieken kann.
For the rest. You and alain are the code gurus. I am just a user - with eleven years experience in end user support. 8000+ plus posts - mostly idle chatting.
That gives me a big history: in trial and error.
I already know how others fixed some problems - or what ways to try.
Serious. alain code does something that I do not comprehend.
So I moved my macro commands into a position/order that works in XP SP3.
I knew that this reordering might help somtimes.
I tested my code snippet at different positions in the macro till all worked
A mere workaround until You code guru guys' fix it because You know the reason.
p.s. I'd never fix anything that works. I am lazzy and do not care why.
Hope I understood Your post.
Der neue Code ist langsamer als meiner für Win OS.
Edited 1 time(s). Last edit at 11/15/2014 07:18PM by guenter.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
JujuLand
Date: November 15, 2014 08:40PM
Hi, guenter and Siria,
what goes wrong with the kmm I send ?
The os test ?
It works in mail.kmm that you have on your computer ...
$tux is a global variable created in main.kmm.
So, $URL for Linux works ok. does $URL for Windows fail ?
I really don't understand.where is the problem ...
Siria, here is the modified main.kmm which allows to have functions like about, ... to be opened in a new tab instead of a new window (but which also allows new window. Now we have the choice ...
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
Edited 2 time(s). Last edit at 11/15/2014 08:50PM by JujuLand.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 15, 2014 09:06PM
Quote
JujuLand
here is the modified main.kmm which allows to have functions like about, ... to be opened in a new tab instead of a new window (but which also allows new window. Now we have the choice ...
Yes that attachment contains the main.kmm modifications that were introduced in KM1.6, guess by desga in a later beta version but not sure anymore. And then Dorian dropped them again because he reinvented the wheel and based KM74 on KM1.5.4 again. Or was it the first beta?
Anyway, the point is, I understand what it does, it's very clear from its code and very simple. But those modifications in main.kmm have absolutely nothing to do with this mimetypes macro and the hidden lines in it. There is no relation, with or without those ominious hidden lines. Main.kmm does not determine what other macros do. And why frames?
The whole "secret" whether a page is opened in a new tab or in a new window is simply this:
Define the URL with
$OpenURL="...."
then fire
&OpenURL_InNewWindow = opens a new window
&OpenURL_InNew = opens a new tab if tabs plugin is enabled, otherwise a new window
That's not exactly "guru" stuff guenter! Even you can do that, after ten years of user support with 8000+ postings :cool:
Edited 4 time(s). Last edit at 11/15/2014 09:16PM by siria.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
JujuLand
Date: November 15, 2014 09:19PM
ok, but if someone wants to change this behavior, he must change the macro, else just a pref, which can be done if Dorian accept to reintroduce it, with a included macro or in kmprefs.
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
Edited 1 time(s). Last edit at 11/15/2014 09:19PM by JujuLand.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
JujuLand
Date: November 15, 2014 09:23PM
@guenter
$OpenURL=($tux==""?"chrome://rvjmimeedit/content/pref/pref.xul":"file:///".getfolder(RootFolder)."/browser/extensions/{fb4eaeed-d1c9-45d1-a2bb-f2876142daf0}/chrome://rvjmimeedit/content/pref/pref.xul"); &OpenURL_InNewWindow;
This line don't work, and I haven't tried to use file:// for xul
chrome://rvjmimeedit/content/pref/pref.xul
works. So we can simplify it, but the size isn't ok, the box takes all the window.
What is trash ... using about:addons, does not have this problem ...
Is it ok with Windows ?
For mimetype.html, I confirm that chrome://rvjmimeedit/content/pref/mimeType.html doesn't work ...
It seems that chrome:// is just accepted for xul, not html ...
[Edit]
I have now saw that I forgot to put html file in jar file, so chrome:// works :mad:
openinNew is ok ...
For xul, as I my first test gives a trash display, I tried reducing K-Meleon (not maximized), and the mimetype window had a correct size. Now maximizing K-Meleon, after restart, I don't have anymore that trash display.
I don't understand ...
I found a pref :
user_pref("extensions.rvjmimeedit.openinwindow", false);
I don't write, and it won't can explain it. Removing it, it works always correctly ???
so we can simplify it.
I'll post a new one tomorrow
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
Edited 2 time(s). Last edit at 11/15/2014 10:00PM by JujuLand.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 15, 2014 09:46PM
Of course the mime-html can't work with your jar, because you keep that file in the chrome parent folder instead of the chrome content pref folder. Move it there and try again?
Quote
JujuLand
ok, but if someone wants to change this behavior, he must change the macro, else just a pref, which can be done if Dorian accept to reintroduce it, with a included macro or in kmprefs.
The way your macro is build, he must edit your macro too and unhide those lines. And then there's the prob, that your extension doesn't create this openinwindow-pref anywhere, at least I can't find it? And of course no GUI for the user either to toggle it. If he doesn't study the code carefully he'll never even guess this possibility exists.
Considering this it doesn't seem much harder for him to change "...InNewWindow" into "...InNew" in the kmm.
No idea what Dorian would have to do with that pref, it's clearly an extension-specific pref, not a global one.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 16, 2014 04:35AM
Hope I understood all.
1.) I always work with an unaltered K-Meleon for such things.
What are You telling me about what main.kmm I use?
The official nothing else. Because it must later work with it.
Quote
JujuLand
&OpenURL_InNewWindow = opens a new window.
That's not exactly "guru" stuff guenter! Even you can do that, after ten years of user support with 8000+ postings
2.) You are right, that's not exactly "guru" stuff, alain!
It IMHO forces to open a new XUL window with the default size that I gave in one of the dtd.
And I know that You know that too because You did the French translation during all the years.
Translators know about size in dtd.
If we give users that choice You seem to want to give - some are bound to complain.
The macro opens the pref.xul at a size that is similar/comparable to the size that is opened forcibly by the Firefox style Addon Manager. So I guess there might be a reason for it.
But that is not my real reason. So let me explain my idea.
I choose chrome://rvjmimeedit/content/pref/pref.xul plus &OpenURL_InNewWindow because if we go via about:addons we cannot switch or drag so easy to/before chrome://rvjmimeedit/content/mimeType.html.
Only when &OpenURL_InNewWindow and pref.xul is used directly You can IMHO always drag the xul window before the html info page while You are editing. And the XUL window must not fill the whole page. No matter what open window/tab setting the user has as default preference.
That was my idea and concept.
That is why I wrote as comment into the kmm:
# We always want this as separarate Window so we can drag it before an open mimeType.html
So &OpenURL_InNewWindow is by my design. I do not want the user to have any choice for a practical reason.
Else I may generate a FAQ.
How can I drag the editor before the info page?
And I sure do not want to answer that.
p.s. Some XUL pages remember what size etc. they had last. Mozilla XUL feature. IMHO Pref.xul we use has it. https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/persist
That is stored somewhere. If I remember right in an rdf.
Edited 2 time(s). Last edit at 11/16/2014 05:27AM by guenter.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
JujuLand
Date: November 16, 2014 08:47AM
Quote
guenter
You are right, that's not exactly "guru" stuff, alain
In my imagination, a guru has a long beard and lives alone in the high mountains and down from time to time in the plain to find his fervent followers ...
I do not have the beard for a long time, I am not alone, I live full time in the plains and have not yet met followers. So even if I could caress hope, I could never call myself guru.
Have I argued, first?
I'll post a simplified version.
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
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
JujuLand
Date: November 16, 2014 12:12PM
Here is the last version with all the needed files updated.
Tell me if it's ok.
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
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 16, 2014 02:05PM
Technically Ok.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 17, 2014 12:36AM
Much better. Almost matches again mine and guenters cleaned up version on the first page :cool:
Except one important point that's still missing. So, since we still can't find an agreement about allowing the native editor too, I finally decided to give in and create a "fork" macro.
Did some testing now, just trial-and-error, and to my pleasant surprise found that KM1.6 can run RJV too!
Even much easier than KM74, all KM1.6 needs is to have rvjmimeedit.jar + manifest in the KM/chrome folder
For our macros the KM version doesn't matter anyway, since they are only about menu building, and thanks to the special chrome-links the editor-paths are the same in all versions.
The result of that testing was that both editors are really needed parallel, because each one is missing a function that only the other one can. Unless that's only in KM1.6, but have doubts that in KM74 the editors work any different - or do they??
So if anyone wants both editors at the same time, install rvjmimeedit.7z from above in KM74 (in older KM versions extract only rvjmimeedit.jar + manifest and put them into the KM/chrome folder). Then add this alternative menu macro:
copy the text below into a new notepad document, and save it as "MimeEditRVJ.kmm" (with option "all files") into a KM/macros folder:
#----------
#UTF-8 K-Meleon Macros (http://kmeleon.sourceforge.net/wiki/index.php?id=MacroLanguage2)
#
# ---------- MimeEditRVJ menu macro (for MIME Type Editors)
#
# Version: 1.0 / 2014-11-16 / by siria (FORK of rvjmimeedit-macro by jujuland+guenter)
# Forum: kmeleonbrowser.org/forum/read.php?1,130230
# Menu: Edit > MIME Types
# Dependencies KM74 : xul addon "rvjmimeedit" (several files+folders / the menu macro (kmm) can be disabled)
# Dependencies KM1.6 : rvjmimeedit.jar + manifest in folder K-Meleon/chrome
# (Tested only in KM1.6 yet)
#
# This is only a menu macro. It uses two mime type editors parallel, the native mtypes-editor
# and the alternative RVJ-editor. RVJ can create NEW mime types, which the native one can not.
# RVJ also allows to define the "always ask" function for single types.
# But the native editor can edit AUTO-mime types, the RVJ-editor only manual types.
# This macro creates a menu to open BOTH editors, depending on which function you need.
# ----------------------------------------------------------------------------
MimeEditRVJ_typesInfo{
macroinfo=_("MIME Types list for information");
$OpenURL="chrome://rvjmimeedit/content/pref/mimeType.html";
&OpenURL_InNew;
}
MimeEditRVJ_edit{
macroinfo=_("Change file type settings (MIME Types) with RVJ-editor");
$OpenURL="chrome://rvjmimeedit/content/pref/pref.xul";
&OpenURL_InNewWindow;
}
MimeEditRVJ_new{
macroinfo=_("Add new file type (MIME Type), open with info list");
&MimeEditRVJ_typesInfo;
&MimeEditRVJ_edit;
}
#---------- Fallback workaround
# if native mtypes-macro was disabled or if rvjmimeedit-macro is active, which conflicts with it:
MimeEditRVJ_mtypes{
macroinfo=_("Change file type settings");
$OpenURL="chrome://kmprefs/content/pref-filetypes.xul";
# $OpenURL="chrome://kmprefs/content/pref.xul?filetypes";
&OpenURL_InNewWindow;
}
_MimeEditRVJ_checkNative{
if (index($macroModules,";rvjmimeedit;") > -1)
setmenu("Preferences",macro,"MIME T&ypes (KM editor)",MimeEditRVJ_mtypes,"MIME T&ypes...");
else
index($macroModules,";mtypes;") > -1 ? 0 : setmenu("Preferences",macro,"MIME T&ypes...",MimeEditRVJ_mtypes,-1);
}
#---------------
_MimeEditRVJ_BuildMenu{
&_MimeEditRVJ_checkNative;
setmenu("Preferences",macro,"MIME Types (RVJ+InfoPage)","MimeEditRVJ_new","MIME T&ypes...");
setmenu("Preferences",macro,"MIME Types (RVJ-Editor)","MimeEditRVJ_edit","MIME T&ypes...");
### setmenu("Preferences",macro,"MIME Types Info List","MimeEditRVJ_typesInfo","MIME T&ypes...");
}
#------------------
$OnInit=$OnInit."_MimeEditRVJ_BuildMenu;";
$macroModules=$macroModules."MimeEditRVJ;";
Edited 2 time(s). Last edit at 11/17/2014 12:47AM by siria.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 17, 2014 05:09AM
Thank You for the macro siria.
siria the reason is IMHO in the XUL code. Both items called by the two macros have the name "pref.xul" and the same "ID". IMHO that is the deeper reason. Since Your macro works around this problem You have found this out too.
There are several other things to do also. Some things that I can do and some that I cannot. So I did not start at all. Change options URL and code name and ID that belongs to it, add icon, new ID (number belongs to Bob Janc - there should not be two add-ons with the same ID and the same name for the addon), clean code inside jar, add homepage to install.rdf (this thread), add icon location to install.rdf... and finally we need a solution so that the kmm can be inside the add-on so that it can be removed with the addon.
And possibly in the macro code of alain who re-used the string "mtypes".
In my macro I had avoided using the same string again.
Nice to know that I could use this version for 1.6 too.
Edited 2 time(s). Last edit at 11/17/2014 05:43AM by guenter.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 17, 2014 09:59AM
Quote
guenter
the reason is IMHO in the XUL code. Both items called by the two macros have the name "pref.xul" and the same "ID". IMHO that is the deeper reason. Since Your macro works around this problem You have found this out too..
No, sorry, can't be. Or do you see anything in my macro code that would modify the name of those xul files or their IDs??
The truth is much simpler: both our *KMM* macros create only menu lines, and those only call a url, nothing else.
Creating menus doesn't modify any xul or other files. So disabling the native macro (kmm), what the latest 7z package does, only removes the native menu lines, not modifies their called target pages (url). The 7z package disables this native menu via a global default pref and uses conflicting identical macro-commandnames.
Perhaps the other (non-kmm) files in the 7z may manipulate the native xul too in some way? Since I have not copied over the other files, this doesn't happen in my old KM anyway. My own little kmm sure doesn't modify any xul files, just take a quick look inside.
But as for the other files, you could do a simple test in your original KM74 installation? If you add only the latest extension (not my kmm), then restart KM and call F2>FileHandling>By Type: Does this pref tab still use the native editor (without "add new" button), or is it replaced with the RVJ-editor??
If still native, then you can use both editors parallel without needing my changed kmm at all. Then both xul's are still both active at the same time. Despite the hidden native menu. A user just has to know that alternative entry point first.
Why only remove the kmm??Quote
guenter
and finally we need a solution so that the kmm can be inside the add-on so that it can be removed with the addon..
A kmm is very easy to remove or disable, it's an additional file, and it's the known default location to extend KM. So users can disable kmm's in the pref sheets or even just delete the files. But the other files that addons like this create outside the add-on itself are far more difficult to remove, and even to figure out! Like the overwritten default sheets for filetypes, and the files creating other default prefs etc. Removing those and replacing again with the original ones is far harder for a clueless user. So please leave the kmm in the macros folder for now, it's far more important to move the other files inside the add-on.
Edited 1 time(s). Last edit at 11/17/2014 10:00AM by siria.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 17, 2014 10:52AM
Quote
guenter
Both items called by the two macros have the name "pref.xul" and the same "ID". IMHO that is the deeper reason. Since Your macro works around this problem
As mentioned, my macro doesn't touch those and the editors still work fine (in KM1.6), but since you use more files for KM74, rdf etc., who knows what those do.
But why don't you simply rename the stuff you suspect and then look if the behaviour changes in any way? Trial and error, and only practical tests will show the truth.
Also if the homepage is nothing but a tag in rdf (is it?), why not simply look how other extensions add their homepages and then just try adding it the same way? If that avoids potential conflicts it would be worth at least trying, why not?
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 17, 2014 12:49PM
You IMHO knew why You used pref-filetypes.xul instead of pref.xul in Your macro.
So do I. That elegantly avoided the problem, same name, same ID.
So You also think the string "mtypes" is conflicting. I was not sure.
I know what I have to change in the install.rdf. That is trivial.
My problem is that I hesitate to start when I do not know all. Which I don't.
Your splendid macro makes the two XUL extensions/prefs work side by side.
So why should I tinker with the addon before kmm can be in addons?
disrupted made the extension manager because normal users have problems with removing items likes macros etc. from their folders.
p.s. Ich hab schon was geändert, weiß aber nicht, ob ich alles mache und wann.
Du brauchst unter 1.6 nur <dialog id="options" statt <dialog id="prefDialog"
in pref.xul eintragen und die Datei in options.xul umbenennen. Es gibt vermutl. noch 1000 andere Möglichkeiten. In den Macros diese Änderung eintragen, die störenden mtypes in rvjmimeedit.kmm ändern, und los gehts. Für 74 ist es etwas - aber kaum mehr. 3 Coder 3 Wege. Oder mehr? Lach.
Dein Macro ist eine Wucht. Besonders wo du zwei Fenster gleichzeitig öffnest!
Edited 3 time(s). Last edit at 11/17/2014 07:49PM by guenter.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 17, 2014 08:07PM
Quote
guenter
You IMHO knew why You used pref-filetypes.xul instead of pref.xul in Your macro.
So do I. That elegantly avoided the problem, same name, same ID.
LOL! Yes I know why, but you're assuming wrong again
You still cling to your deep conviction that it must be something "complicated", but really, the name of the link targets don't make any problems (they ARE different before the ending), at least not in my KM1.6.
All 3 xul-editor links work perfectly, have tested it! (you could test too, but don't seem to bother)
The only reason I chose the other page is that as a side-effect the visible layout difference tells me whether the native mtypes is active OR the rvjmimeedit-macro. Just for curiosity!
The native one can coexist peacefully with all other macros that follow kko's macro guidelines, but rvjmimeedit comes 1) with a default pref that disables it intentionally, even in new profiles and 2) also with a conflicting command name "macros(mtypes)".
Why do you find it so difficult to understand that it *cannot* possibly work to call one editor with the command "macros(mtypes)" and then another editor with exactly the same command "macros(mtypes)"?
Look inside native mtypes.kmm, perhaps you understand better then (it's just a tiny 1-link-macro). I had mentioned in one of my first replies already that the same name gives conflicts, later I rewrote the macro myself and changed the conflicting name, you added more improvements, it did work fine parallel at that time already. Alain didn't want any of it and changed all back, a bit later yourself changed the conflicting name again, and again he insisted to change it back, and also added the pref to automatically disable mtypes.kmm. Is it really such a wonder that those two macros don't work parallel that way?
Therefore, if rvjmimeedit is among the active macros, mine must restore the link to the native editor again, otherwise not. So just because I'm curious, to see if the current link was created by the native macro or by my copy of it, I chose to use a slightly different editor link. Which looks exactly the same anyway, just without sidebar. If you don't want to know which macro created the current menu, you can just as well use the pref.xul link again. That's exactly why both links are still included.
But hey - you can very easily demonstrate to yourself if parallel use is possible or not: Just open the native editor! If the menu link was disabled, open it via F2>FileTypes. The layout and (missing) buttons show which one it is.
Another indicator: if you put a new, nearly empty DEFAULT mimeTypes.rdf in the current profile (as it was before overwritten with the rvj-template), then even the content is different: the native editor shows also the automatic plugin entries, RVJ not, it can't see those. At least when I test it, but there are no other testers around. Your huge list is handy of course, just for testing such differences a bit too long.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
guenter
Date: November 17, 2014 10:32PM
siria, ich habe mtypes kmm mal gemacht - na ja, ne noch ältere Version geändert.:O
Egal. Ich bin mit meinem Ding fertig. Danke für deinen Makro Beitrag.
Werde mal in einer stillen Stunde hoch laden.
p.s. Das einzige was ich noch gern wissen will - wie tut man die kmm in das Add-on.
Das hatte Dorian ja mal getan.
Hier ist mein Makro schon mal. Ich glaube du verwechselst alains mit meinen kmm.
# K-Meleon Macros (http://kmeleon.sourceforge.net/wiki/index.php?id=MacroLanguage)
# ---------- kmimeedit Extension (MIME Type Editor) -------------------------------------------------------------------
#
# Dependencies : main.kmm (OpenURL)
# Resources : -
# Preferences : -
# ------------------------------------------------------------------------------------------------------------------
mytypes{
macroinfo=_("Edit mimetypes");
$OpenURL="chrome://kmimeedit/content/pref/options.xul";&OpenURL_InNewWindow;
}
mimetypes{
macroinfo=_("MimeTypes information");
$OpenURL="chrome://kmimeedit/content/pref/mimeType.html";&OpenURL_InNew;
}
KMimeEdit_new{
macroinfo=_("Add new file type (MIME Type), open with MIME Type info list");
&mimetypes;
&mytypes;
}
aboutaddons{
macroinfo=_("Addons Manager");
$OpenURL="about:addons";&OpenURL_InNew;
}
# ----- PRIVATE
_mytypes_BuildMenu{
# edit menu
setmenu(Preferences,macro,_("Edit mimeTypes.rdf + Types Info"),KMimeEdit_new);
setmenu(Preferences,macro,_("Addons manager"),aboutaddons);
}
$OnInit=$OnInit."_mytypes_BuildMenu;";
# ------------------------------------------------------------------------------------------------------------------
$macroModules=$macroModules."kmimeedit;";
Edited 1 time(s). Last edit at 11/17/2014 10:33PM by guenter.
Re: Problem opening .pdf files / MimeTypes extension
Posted by:
siria
Date: November 17, 2014 11:36PM
Oh, yet another... hmm... let me guess, it's just a renamed copy of rvj-editor? Or not?
But please, do a little **TEST** before publishing the final version. You guys never seem to test your own stuff! As this thread has shown again and again and again, and I don't get it...
While I see already at first look another little menu glitch.... but I leave the discovery to your test, it's really extremely easy :-P
But how about finally starting a little crash course in macro writing? :cool:
(I know little people bother to stick to it, but still kko's guidelines make a lot of sense and reduce conflicts):
Especially the lines about naming conventions for macro names (the single command blocks inside the kmms)...
http://kmeleon.sourceforge.net/wiki/MacroGuidelines
And kko also recommends:
(the native macros do follow this, there are no _() in their setmenu lines)Quote
kko
Note that <menuName> and <itemName> are translated automatically if possible. In regard to the browser's startup performance, do not use the _() statement in conjunction with setmenu().
Not to be too nitpicky, but if this is about to get a final publish, the typos in the mime-list could get corrected. Just a global text replacement for "extention" -> "extension", takes only a few seconds.
Whether about:addons belongs in a mimetypes macro may be a matter of opinions. Why I finally had removed it was the thought, that this command should really be a native one by Dorian, and hopefully soon, and then it would be double. And also my impression had been that in the beginning it only was used in the mimetypes-macro because the direct pref.xul path didn't work yet (which obviously turned out wrong), and now it's not necessary any more for a pure mimetypes macro.
And the header is IMO still lying if it claims that no other files of any kind were needed for this extension to work, only this link macro. Makes it much more difficult for users to figure out the rest of the files.
Okay, genug gemeckert ;-) Nur eins noch, bitte den mtypes-killer pref in der js noch rausmachen?
Ah.. doch noch was vergessen: Platzier das Menü wieder direkt über dem originalen, die zusammengehörenden mime-Zeilen brauchen ja nicht sinnlos verstreut werden (s. Ende von setmenu)
Edited 2 time(s). Last edit at 11/17/2014 11:46PM by siria.
English