Firefox 4 comes soon (ok, next year ;)) and there is a Firefox plugin to sync your bookmarks etc. with Firefox 3.whatever .
I would like to know if anyone has a comprehensive, up-to-date tutorial to integrate Firefox Sync into your own plugin? Or any idea regarding this?
I mainly followed this official "tutorial" and also this blog post, but the information seems to be slightly outdated.
For example, the object is not called Weave anymore but Engines and the weave.engines. preference became services.sync.engines.. I played a little with all the mentioned options, but it does not seems to work (and my plugin does not show up in list where you can select what to sync).
I assume that the Tracker and Store classes are fine, the main problem is to register the engine...
The ClientAPI tutorial you mention is definitely the way to go. I updated it recently so if something's not working, please let us know so I can fix it in the docs. Wladimir's blogpost is definitely quite old and contains some outdated information. We will also make changes to some parts of the API in the upcoming beta releases, so be prepared for some flux...
The Weave namespace is still the canonical way to access Sync related APIs from UI code. It exposes components such as Weave.Service and Weave.Engines. You can import it via Components.utils.import("resource://services-sync/main.js"). If you want to implement your own engine, you'll have to import the actual underlying modules, though (all listed in the ClientAPI tutorial). The tutorial also describes how to register your custom engine implementation. Once it's registered, it won't automatically show up in the preferences UI, though. I suggest building your own UI that flips the services.sync.engine.YOURENGINE pref in your add-on's preferences.
Out of curiosity, what kind of data are you trying to sync?
Related
In this video (https://www.youtube.com/watch?v=qPHKWsZK2Jc&list=PLvv0ScY6vfd-p1gSnbQhY7vMe2rng0IL0&index=10) from about a year ago, there is example code on the SDL_CreateWindow function documentation page. I have seen other posts talking about the SDL examples.
If you look at the documentation now it is the same minus the example code
https://wiki.libsdl.org/SDL2/SDL_CreateWindow
Am I blind or is there no longer any example code on the SDL2 wiki?
If not, does anybody know what the reasons for removing it are?
I expect that
There are some official examples somewhere
If they were removed from the official wiki they would at least be placed in a 'legacy' repo or something like that.
A Google (DuckDuckGo) search gives only third party examples and, aside from a few forum posts, no mention of there ever being any examples on the wiki.
In 2022, the Wiki migrated from MoinMoin to ghwikipp. With that came a host of breaks and bugs. Your issue specifically is covered under issue #233.
The images were also broken, but that issue shows a workaround for viewing the Wiki in working form: use archive.org on wiki.libsdl.org, not wiki.libsdl.org/SDL2 where it is currently hosted. This gives you your examples back.
e.g. like this
If you have some sort of MediaWiki viewer program, you can also just pull an old revision from the Repo and read it offline. Even Github's MarkDown viewer isn't terrible. Caveat that new changes won't be reflected.
They promise us that it will be fixed at some point, and they do seem to be working hard on it. The only hardfix is either to (a) wait, or (b) help them finish their migration.
I'm learning Parse (the Javascript flavor) using their Todo App tutorial. I'm trying to write my first query. In the tutorial, I found this code:
var TodoList = Parse.Collection.extend({ ... });
I can't find any info about Parse.Collection in their JS Guide nor their API docs.
Can someone shed some light on what a Parse.Collection is and when I should use it?
You're not seeing anything in the docs because Parse.Collection was removed from the JavaScript SDK in v.1.6.0.
Downloads Page and JavaScript Changelog
SDK no longer contains Backbone-specific behavior. Moving forward, the core SDK will not be tied to any single framework, but we will work with the community to produce up-to-date bindings like Parse+React. The major changes are the removal of Parse.Collection, and allowing Parse.Objects to act as event channels.
In previous versions of the SDK, Parse.Collection was used almost identically to Backbone.Collection, as the Parse SDK was based on Backbone. Things are particularly confusing right now because tutorials on parse.com use pre-1.6.0 versions of the SDK.
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
I know some of the tutorials for creating Xcode project templates, for example this one here: http://robnapier.net/blog/project-templates-364
This is the best one I could find. All others basically repeat the same info, or are no longer up to date, or worse tell me that even they don't know what they're doing. Possibly useful tools that are linked to here and in other places are no longer available.
I keep running into roadblocks, and would like to gather as much information as possible on the process of creating Xcode project templates. Info that is most importantly up to date (at least it must be relevant for Xcode 3 or higher).
For example, what I'd like to see is:
a description of the
TemplateChooser.plist and similar
plist files and what these options do
(in my case, once I add a
TemplateChooser.plist, my project
disappears from the Xcode project
template list)
how to create a project template that references another .xcodeproj (when I do that, the other .xcodeproj appears in the project template list even though it doesn't use the special naming convention)
processes that can be applied, for example is it possible to run a script during the creating of a project from a template? This would be useful to unzip certain files into the newly created project.
If you have the answer or suggestions to any of the issues above, I'd appreciate that. Otherwise any link to good Xcode project template resources would be highly recommended. Especially if there is an official documentation from Apple - I haven't found one yet which seems to imply that project templates are undocumented.
Have you seen these:
http://www.sodeso.nl/?p=895
http://www.codeproject.com/KB/iPhone/CreatingXcodeProject.aspx
If you say you have searched, I'm pretty sure you've already seen the links but these are the best resources I could find with my 'googlabilities'
You might try contact this guy - http://linkedin.com/in/mottishneor he has some related messages around the web
The links suggested by FX are also not bad at all!
There is indeed little XCode template info out there. What I have found of interest are the following links (I documented myself on the topic, but haven't yet gone any further):
a Google Code search reveals a few examples, but not much
in particular, I found interesting to look at the code provided by Three20; they have some basic examples, like here
referencing another project worked for me, so maybe you could open a specific question about that giving more details?
there is information scattered on the Apple mailing-lists
there is no official documentation from Apple, as is evidenced by the lack of results to this query
I'm sorry if this is not a Enlighting, concise answer. As you said, it's not well documented, and sources are all over the place. I just hope I could highlight some places to find information that your own searches might not have reached :)
I don't have a Mac anymore, so this is as much as I can give you without testing this myself. As far as I can tell, Xcode templates are undocumented by Apple.
This guy has some guides for messing with Xcode templates but the info is pretty sparse. My suggestion for working with templateChooser.plist is to try to only edit that file in the interface builder.
This guide is a good example of how to add a reference to another .xcodeproj. For the reason you were having trouble adding a reference to your project we probably need more information.
If you scroll way down in this doc you can that each template already includes a script called myscript.sh. This script will show up in the scripts menu for projects built with that template. That isn't quite as convenient as running scripts automatically, but it's better than nothing.
In conclusion, Xcode template documentation is a nightmare. It looks like there are a lot of powerful features there, but they are obscured because of lack of user friendlyness and because documentation lags far behind Apples updates of Xcode. It just doesn't seem to be a priority for them. I hope this helps.
And yet another video link http://howtomakeiphoneapps.com/2010/10/how-to-make-custom-xcode-templates-with-video/
Someone on here recently recommended BWToolkit, and it really impressed me, so I started googling for more IB plug-ins. I've found a couple on random blogs, but haven't been able to find any kind of repository/aggregator for them. Anyone know where I can find more of these?
Thanks.
I just created a page on CocoaDev to list them [edit: question originally just said “Interface Builder plug-ins”, did not mention Cocoa frameworks], with the two I know of listed.
Well that's a good start. I guess that wiki page is the de-facto repository, for now. Seems like there's not much out there.
You are not looking for Interface Builder plug-ins. You think you are, but you aren't. BWToolkit, the example you use in your question, is not an Inteface Builder plug-in. Brandon bills it as an Interface Builder plug-in but it is actually a framework and a plug-in. The framework contains the actual controls. The plug-in contains the integration with Interface Builder.
So really, what you are looking for are frameworks that contain or provide Interface Builder plug-ins. I have changed your question to reflect that, so it is more likely to be found by people using Google to search for similar things in the future.
I know what I am looking for. Not all frameworks contain IB plugins. I am looking for a specific subset of frameworks, those which contain IB plugins. An IB-plugin without a framework is useless, therefore the framework part is assumed. I am NOT looking for regular old frameworks, so stop trying to change my question to that. Your additions only seem to be confusing people.
I have reported your post, hopefully moderators will be able to stop your obnoxious behavior.
"Without a framework, what would you have to plug in to IB?"
Your words, not mine. Anyways, I'm done arguing this with you. Just remember that I can roll back for every time that you edit.
It's clear you have a lot of experience in this field, but instead of offering answers you decided to nitpick where there are no nits to pick.
Additionally, you have not "changed the question to refelct that," you have changed the question to a completely different question. I would have though that after four rollbacks you would relaize that you're doing more harm than good. Just stop, okay?
Of course, Chris Hanson is absolutely correct when he says that an Interface Builder plugin is useless without an accompanying framework. Interface Builder merely provides a graphical way to manage objects in a framework; without the framework itself, Interface Builder has nothing to manage.
However, I do think that there is a completely valid sort of Interface Builder plugin that wouldn't necessitate the installation of an accompanying framework, and that would be one that provides Interface Builder integration features for objects in Cocoa/Cocoa Touch which would otherwise appear as just generic objects.
For those of you who come to this page Google, please recognise the difference between Interface Builder plugins and frameworks: even the examples mentioned above work on frameworks (they could be Foundation, AppKit, UIKIt, etc.)