I built two separate Firefox extensions which are fundamentally incompatible with each other. The incompatibility is by design, as it would be totally unlogical for a user to install both. While I can stress out in the doc that both shouldn't be used at the same time, I don't trust the user to read the doc, and I'm looking for a way that one extension could detect the presence of the other and either disable itself or the other one (ideally while popping an error message).
Is there a way for an extension to be aware of the presence of another extension? I know it's possible for an extension to specify it depends on another one, but what I need is the exact opposite, a way for an extension to specify it conflicts with another one.
Firefox Addon Development : Detecting non-compatible addons?
Related
I'm developing a site for my company and I also need to modify the native component "mailto" to fit our needs.
I'm working with a joomla 2.5
I was wondering if future updates occur, what will happen to the lines I've added, for example, in "\components\com_mailto\controller.php"...
I haven't find answers on the net.
Also, for the same reason, I've modified the default layout of an article. Should I rename it? and if yes, how, because I couldn't do it (when I've tried the article did not display).
Thanks for your help
Before starting to edit core Joomla components, should should always have a look at the options you have. I don't believe in editing core file as it simply causes problems for updates when released, therefore in my opinion, you have 2 options:
I always make a note of all my requirements and start looking for a 3rd party extension that caters for my requirements.
If I cannot find a 3rd party extension and don't particularly want to start digging into it's code, I would go with developing a plugin. Plugins are used to manipulate the behavior or something and therefore come in extremely handy for when you would require core editing.
Editing the layout of an extension view is completely fine, but it's strongly recommended you make a Template Override so that if the extension does ever get updated, your changes won't get overridden.
So to answer you initial question, any line you have added to the controller.php file will get overridden when you decide to update the extension.
Hope this helps
While the answer from Lodder is totally valid, as a last resource you can also consider forking the com_mailto as a separate component.
This has some disadvantages:
you need to rename all the files involved (controllers, models, views)
you need to maintain it and keep in in sync with future updates (consider than you are now on 2.5.x and in a year you might want to upgrade to 3.x).
I have a Mac "Shoebox" app that internally uses NSDocument objects, but does not expose the concept of individual documents to the user. (I rely on NSDocument to make syncing via iCloud easier.)
My problem is that when a version conflict arises, my app shows the default NSDocument conflict resolution alert (see below) letting the user pick one or two winners.
In the concept of my app this doesn't make sense. Is there a way to intercept/prevent that alert and handle the conflict programmatically?
I know that I can detect version conflicts with the code below. However, I still need to prevent the alert sheet.
[NSFileVersion unresolvedConflictVersionsOfItemAtURL:document.fileURL];
Example conflict resolution alert:
This is the built in behavior of NSDocument when it discovers there are unresolved version conflicts. If you do not wish to use it you'll have to drop support for NSDocument and use a lower level abstraction like NSFileManager + NSFileVersion.
You can override + (BOOL)usesUbiquitousStorage and return NO.
This will no longer show the ubiquity conflict panel.
See the doc Resolving Document Version Conflicts
Strategies for Resolving Document Version Conflicts
Your application can follow one of three strategies for resolving document-version conflicts:
Merge the changes from the conflicting versions.
Choose one of the
document versions based on some pertinent factor, such as the version
with the latest modification date.
Enable the user to view
conflicting versions of a document and select the one to use.
Which strategy is best to use depends a lot upon your document data. If you can merge the contents of different document versions without introducing contradictory elements, then follow that strategy. Or choose the document version with the latest modification date if your application doesn’t suffer any loss of data as a result.
Generally, you should try to resolve the conflict without involving the user, but for some applications that might not be possible. If an application takes the user-centered approach, it should discreetly inform the user about the version conflict and expose a button or other control that initiates the resolution procedure. An Example: Letting the User Pick the Version examines the code of an application that lets the user select the document version to use.
I'm new to Firefox extension development, friendly speaking it's first day, I had followed the following article in order to start with Firefox extension development: How to develop a Firefox extension.
If I download the example from above given link's tutorial and try to install, it is installed perfectly but, when I update that example (just updating its name to the new extension name, where it is necessary in all files), and then install, I get the following message: "X could not be installed because it is not compatible with Firefox 15.0.1." (where X is the name of my extension).
Strange behavior same code one is installing fine and other one giving error.
Any idea where it is going wrong and what is causing this?
The problem is that you forgot to adjust the compatibility range in install.rdf so em:maxVersion is still saying 3.1b2 (meaning Firefox 3.1b2 - a rather old version). You should change that into 15.* if you want to support the current stable Firefox version or 16.* if you want to support the current beta versions. You can also change em:minVersion into something more meaningful: I doubt that you will verify whether your extension still works with Firefox 2.0.
As to why the extension installs if you don't change the extension ID, this is more complicated. First of all, there is a soft override mechanism for the compatibility ranges which allows extension authors to change the compatible version range without releasing a new version. In this particular case Firefox will check for extension updates by requesting this address or a similar one. The update server tells it that version 1.0 is still current but adjusts maxVersion to Firefox 8.0 - this value will override whatever is specified in install.rdf.
But that's not the end of the story. The compatibility check mechanism was changed significantly in Firefox 10, the default assumption is now that the add-on is compatible with newer versions even if that isn't specified explicitly anywhere. The requirements are that the extension doesn't opt out of lax compatibility checking, doesn't contain binary components and is compatible with at least Firefox 4. The original extension is compatible with Firefox 8 thanks to the soft override, with a different extension ID it is only compatible with Firefox 3.1b2 however (it isn't hosted on addons.mozilla.org so the update server doesn't know about it) which means that the lax compatibility checking doesn't apply to it.
For reference: the behavior described in the previous paragraph is controlled by the extensions.strictCompatibility, extensions.minCompatibleAppVersion and extensions.minCompatiblePlatformVersion preferences.
I am making a QuickLook plugin that will be included with my application. It will be used to preview a file type that other applications also have QuickLook plugins for. Every time I attempt to test with my plugin (I put it into ~/Library/QuickLook/) it previews with another app's plugin. I am using qlmanage to preview. Is there a way to force it to use mine, at least for testing?
Generators embedded in applications are always preferred to plug-ins in ~/Library/QuickLook (which are preferred to the ones in /Library/QuickLook, which are preferred to the ones in /System/Library/QuickLook).
There is no way to change this priority. Also if 2 generators at the same level claims the same type of file, Quick Look will prefer one over the other, whichever you can't control.
At least for your test, you can force qlmanage to use the plug-in you want by using the -g option (but you will also have to specify the content-type with -c).
Try qlmanage -h to get all the options for your tests.
While the order of precedence described by #julien is accurate, it is still possible to override a particular application's QL provider. Simply edit the Info.plist file in the .qlgenerator of the offending application. For example, I like the way a certain QL provider handles markdown, but one of the text editors I have installed includes (imho) less than stellar markdown support. My preferred bundle loses... until I edit:
/Applications/BadMarkdown.app/Contents/Library/QuickLook/BadMarkdownQL.qlgenerator/Contents/Info.plist
and remove
<string>net.daringfireball.markdown</string>
And in newer versions of OS X, you don't even need to restart the QL daemon. The preferred QL tool just takes over. =D
I have custom frameworks in my app bundle for WebKit, WebCore, and JavaScriptCore. I would like all other frameworks that depend on the system versions of WebKit, WebCore, or JavaScriptCore to use my custom versions also. For instance my custom version of Webkit loads private system frameworks that in turn depend on the system version of WebKit. This means both my WebKit and the system WebKit get loaded, and usually a crash happens shortly after.
The way I understand this should be done, is to set the DYLD_FRAMEWORK_PATH environmental variable before your app bundle begins execution (Search order for loading frameworks can be found here: http://code.google.com/p/macdependency/wiki/SearchPaths). You can set environmental variables in code with setenv, but it won't take effect for the currently running process. I would have to re-launch the process again for it to take effect. I would like to avoid this too.
So my question is what is the best way to set the DYLD_FRAMEWORK_PATH before the execution of the my app bundle? This has to work in a release app bundle too. Is there a way to run a script whenever someone clicks on my app bundle before the executable starts running. Or is there any other suggestions out there?
Thanks in advance.
Jeff Wolski has the right idea by referring directly to Apple's documentation on the subject. This thread also provides excellent advice on how to get that going in Xcode, including corner cases associated with alternative methods of specification (for example, by using ~/.bash_profile directly for your user).
My reason for chiming in is you also asked for a script that might be able to assist you (and a bounty provider appears to have the same issue). It turns out Webkit references such a script in its documentation, which you might want to pick apart from the applicable Webkit source code. This should give you additional guidance on how, at least according to the developers, you should do this properly.
Best of luck with your project(s).
I would recommend environment.plist or the LSEnvironment key in the info.plist. Check out the link below.
https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html
WebKit currently has a script to do this for you, called run-webkit-app. See http://trac.webkit.org/browser/trunk/Tools/Scripts/run-webkit-app
Newer versions of ld understand the -dyld_env flag, which inserts a LC_DYLD_ENVIRONMENT load command into the binary (and as such applies essentially as early as possible in app execution). Perhaps adding -Wl,-dyld_env,DYLD_FRAMEWORK_PATH=/folder/encosing/WebKit/and/related/frameworks to your compiler flags might do what you want?