Views UI support

Same here: Subscr

At the moment, you can't.

There are two reasons for this:
First, Views are not using "format" as they key to store the generated Input format selection markup (filter_form()) when building their options forms.
Currently they look like this:

// views/plugins/views_plugin_display.inc, options_form(), around line 900
      case 'header':
        $form['#title'] .= t('Header');
        $form['header_empty'] = array(
          '#type' => 'checkbox',
          '#title' => t('Display even if view has no result'),
          '#default_value' => $this->get_option('header_empty'),
        );
        $form['header'] = array(
          '#type' => 'textarea',
          '#default_value' => $this->get_option('header'),
          '#rows' => 6,
          '#description' => t('Text to display at the top of the view. May contain an explanation or links or whatever you like. Optional.'),
        );

        $form['header_format'] = filter_form($this->get_option('header_format'), NULL, array('header_format'));
        break;

Wysiwyg module specifically looks for the key "format" to know a textarea is input format enabled.
We'd need it to look like this:

// views/plugins/views_plugin_display.inc, options_form(), around line 900
      case 'header':
        $form['#title'] .= t('Header');
        $form['header_empty'] = array(
          '#type' => 'checkbox',
          '#title' => t('Display even if view has no result'),
          '#default_value' => $this->get_option('header_empty'),
        );
        $form['header']['header'] = array( // Modified
          '#type' => 'textarea',
          '#default_value' => $this->get_option('header'),
          '#rows' => 6,
          '#description' => t('Text to display at the top of the view. May contain an explanation or links or whatever you like. Optional.'),
        );

        $form['header']['format'] = filter_form($this->get_option('header_format'), NULL, array('header_format')); //Modified
        break;
// Note: This also goes for other option forms, like the footer.

A simple change which allows Wysiwyg module to know it should attach itself to those fields and to include some JavaScripts for the client.
But this only makes it work when not in Views' AJAX mode (or when JavaScript is completely disabled) as your theme will make sure all scripts are actually included in the output.

When using the Views UI in AJAX mode it won't work, even with the fix above, because Views never sends the scripts added using drupal_add_js back to the client in the JSON response.

Views would need to fetch the JavaScripts collected by drupal_add_js(), add them to the JSON response and then inject them into the page when the response is processed by the client.
They must also be sure to not accidentally inject a script twice as that could cause problems.

I'll put together a patch for Views once I get some time over. I don't think Wysiwyg module will require any patches for this to work even in AJAX mode.

There's already an issue related to this in Views. #376392: Changing input format for header content

It was marked as a support request and has been answered, thus "fixed".
This should not require any changes to Wysiwyg module itself as it's Views' use of Form API that seems to not completely follow the guidelines. (Sorry but I forgot where I read those guidelines.)

I just found a Views issue which is more relevant than the previous one. #345722: edit-header and edit-footer behave funny

Would it seem sensible to change this line (124 in wywiwyg.module)

if ($item === 'format' !== FALSE) && $index > 0) {

to this

if (($item === 'format' || strpos($item, '_format') !== FALSE) && $index > 0) {

or can you imagine some module using a '_format' key without making it a input format?

note: this doesn't work for the views ui, as the form is AJAXed in, so the js doesn't get added and stuff

but it works perfect for my use case, where I'm using views_header_footer module to expose the header on a separate page so my client doesn't have access to the entire view, but can edit the header

+1 for fix #5

It works for me (I'm using the same module to bypass the original problem).

M.

+1 for #5.

+1 for #5. works like a charm.

+1 for #5
Would love to see this fix rolled into the module if it made sense for everyone.

Better title + proper status (no patch here) + proper version and component.

If I get this issue right, then #5 only helps with the http://drupal.org/project/views_header_footer resp. http://drupal.org/project/views_ui_basic module, but not for views_ui itself, because views_ui itself loads those forms via AJAX, which means that all the editor integration scripts are not loaded (which is a different issue).

Regarding views_ui_basic, I wonder why that module cannot simply use the regular $form array keys (i.e. 'format') and just assign different #parents?

The latest version of views_ui_basic has been modified to support WYSIWYG.

#5 helped me, but I had to deal with an issue that wasn't mentioned here, so I'll add it here for reference:

Steps I took:
1) I installed the Views_UI_Basic module
2) Editted wysiwyg module according to instructions in #5
3) Configured the header and footer to show, with Full Html input filter

but the editor would not show ....

I fixed it by making sure that the ADMIN THEME shows up on the views_ui_basic pages. Put the code below into a custom module:

function MODULE_NAME_init()
{
    if (arg(0) == 'views_ui_basic'){
      $GLOBALS['custom_theme'] = variable_get('admin_theme', '0');
    }
}

cheers!

If http://drupal.org/project/views_ui_basic does the job, then that's good enough for us. D7 won't have this issue, so I hope we can happily ignore it for D6.