Add FCKeditor support

My local url to Drupal5 is: http://127.0.0.1/drupal5.
This patch seems to work, but I had to change one thing, because on my installation, editorBasePath was set to:
http://127.0.0.1/drupal5/drupal5/sites/all/modules/wysiwyg/fckeditor (note double drupal5).

According to the definition:
editorBasePath = $GLOBALS['base_url'] . base_path() . $path_editor

Here's the dump of variables:
$GLOBALS['base_url'] = http://127.0.0.1/drupal5
base_path() = /drupal5/
$path_editor = sites/all/modules/wysiwyg/fckeditor

...I removed $GLOBALS['base_url'] and it worked.

Just some quick thougths regarding the wysiwyg module, please consider this more as a quick comment than my final solution for it at the moment:

- .module and .js contains plenty of ugly switch conditions now; intelligent solution required (includes?).

Definitely there must be an other way to work on it. It would be good also if there was a possibility to switch between different versions of the same editor.
Adding new code to the wysiwyg module should be easier - instead of multiple switch/if statements I'd preffer for example creating functions with a special names which would be saved in a separate file(s).

Just a quick proposal:
- add a way to register "submodule" (inform WYSIWYG module that new editor is available), we can have something like built-in submodules inside of the WYSIWYG module, if another developer decide to join WYSIWYG project, instead of changing the core, he'll create his own submodule that will call wysiwyg_editor_register('FCKeditor2').
User will then be able to select FCKeditor2 from the list of available editors.
- then in wysiwyg_editor.install instead of calling
wysiwyg_editor_migrate_tinymce();
do something like:

  foreach ($registered_modules as $m) {
    if (function_exists("wysiwyg_editor_migrate_" . $m)) {
      call_user_func_array(...)
    }
  }

(there is a better way to do it, this is an example to see what I mean)

But actually, any other solution than hardcoding support for all editors with multiple if/switch statemenets in the core would be fine.

"Themes" is a valid layer in FCKeditor, too - but FCK supports even another layer: "Toolbars". So we'd have a) Profiles b) Editors c) Themes d) Toolbars - pretty ugly; needs a redesign

Do you think it's doable to make a profile that would be universal for all wysiwyg editors? There are obvious differences between FCKeditor and TinyMCE, if we add a couple of other WYSIWYG editors we won't get a lot of common settings.
My opinion is that in the Core, WYSIWYG module should provide a way to choose a WYSIWYG editor(s) on a specific field(s) + perhaps add the ability to create a plugin that could be used by all editors (...this might be hard to implement?).

Anyway, at least there should be a way to add custom settings for a specific editor.
I have a feeling that for example things like:
- "Safari browser warning:"
- "Buttons and plugins"
- "Editor appearance"
- "Cleanup and output"
- "CSS"
can't be in the WYSIWYG core, because either each editor implement it in a different way or does not support at all.

Some proposals:
- define in advance some universal sections, like:
i) "Editor appearance"
ii) "CSS"
iii) "File browser settings"
iv) "Cleanup and output"
v) ...
vi) "Advanced Options"

where each editor could present it's own settings, and display straight below which editor supports it.
There is a chance that some editors will display the same setting, then we'll have for example:

Editor CSS:
#Use Theme CSS
#Define CSS
#Editor default CSS
* supported by: FCKeditor, TinyMCE

...does it make any sense?