I have this question especially for qtip (Stylish jQuery Tooltips), but it's a general issue; how to get other and new editing features as buttons inside editors as : WYSIWYG, CKEditor, Whizzywig and XStandard ??!
See: How can we get buttons of qtip inside the best editors? - http://drupal.org/node/916000
For sites where a lot of people can post and respond, it would be more easy and feature rich, if we can make it easy for them to quickly find all the editing features (back), while a button can be quicker than thinking about the format and typing the code.
This issue has to be filed at all these editors, not even at their Drupal modules? Or do some Drupal modules already have an integration of new editing features that another module like qtip can 'throw to them' if it uses the proper way to do so?
Comments
Plugins and extensions via hoooks
I haven't looked at the details of qTip yet so this post will be a summary about plugin handling in the Wysiwyg module.
Wysiwyg module provides a couple of serverside hooks for extending thre editors via existing plugins or by overriding settings. The most useful one for other Drupal modules which wish to use "native" editor plugins is hook_wysiwyg_plugins(). It allows a module to define metadata about a plugin, like its, location (internal to the editor folder, or external with a completely different path), its machine-readable name, download location or official website, its human-readable name, if it's a buttonless extension or if it has buttons (and their human-/machine-readable names), its default settings - all without having to modify Wysiwyg or the editor libraries.
Our implementations of the more popular editors also support cross-editor "Drupal plugins" which work against Wysiwyg's and Drupal's APIs instead of the ones provided by the editors. These are provided via different, but still similar, procedures, starting with an implementation of hook_wysiwyg_include_directory(). Granted, these APIs are currently limited compared to the editors' own APIs and they have a some drawbacks that we need to take care of in the next major Wysiwyg release. There are some pretty cool uses of them though, like the Wysiwyg image upload module.
These hooks have some documentation in wysiwyg.api.php and wysiwyg.api.js.
A more recent addition is hook_wysiwyg_editor_settings_alter(), invoked just before settings are converted from PHP objects to JSON. It's meant more for customizing indivual sites as it has "final say" about what's sent to the browser, but can be useful for overriding complex settings that would be hard to do from hook_wysiwyg_plugins().
like twod said
I would not go with qTip at all, that will no suit the needs of the WYSIWYG Api integration at all. In a lot of case you will need proper API callbacks with a full bootstraped Drupal. I know, for small tasks or "makros" it could be handy, but iam sure its rather more interesting to go 2 approaches, depending on the application
qTip is simply not the tool here. Iam using it in my drupal installation for different things, but it has it downsides and is not really capable of dialogs the way you would think of jquery ui dialog or others.
And for thwe WYSIWYG API drawbacks. In the meantime i have implemented a lot WYSIWYG api driven dialogs and feature, also pretty heavy ones like inline-office-document-import and things. They all work out, just have a look at http://drupal-wiki.com/de/demos under "inhalt editieren" ( sorry german only videos yet). There you can see what you can do with jquery_ui_dialog and the WYSIWYG api.
Also, for the ctools modal dialog stuff, have a look at the "document mangement" video. Thats done with it! 0 JS code.