Porting Scheduler UI

+ */
+function rules_ui_form_execute_rules_config_submit($form, &$form_state) {
+  $component = $form_state['rules_element'];
+  $component->execute();

This should be $action I think. It's the same for rules_scheduler_schedule_form_submit().

+/**
+ * @file
+ * Admin forms for scheduling
+ */

Missing trailing point.

+  $result = db_query("SELECT DISTINCT config FROM {rules_scheduler}");
+  $config_names = array();
+  foreach ($result as $record) {
+    $config_names[$record->config] = $record->config;
+  }

Let's let a DB-TNG helper do the fetching for us. However it seems wrong to me that we have to do it all. Perhaps you could manage it do work directly with the views form?

I found the following code in views generating the form:

  /**
   * Render the exposed filter form.
   *
   * This actually does more than that; because it's using FAPI, the form will
   * also assign data to the appropriate handlers for use in building the
   * query.
   */
  function render_exposed_form($block = FALSE) {
    // Deal with any exposed filters we may have, before building.
    $form_state = array(
      'view' => &$this->view,
      'display' => &$this->display,
      'method' => 'get',
      'rerender' => TRUE,
      'no_redirect' => TRUE,
      'always_process' => TRUE,
    );

    // Some types of displays (eg. attachments) may wish to use the exposed
    // filters of their parent displays instead of showing an additional
    // exposed filter form for the attachment as well as that for the parent.
    if (!$this->view->display_handler->displays_exposed() || (!$block && $this->view->display_handler->get_option('exposed_block'))) {
      unset($form_state['rerender']);
    }

    if (!empty($this->ajax)) {
      $form_state['ajax'] = TRUE;
    }

    $form_state['exposed_form_plugin'] = $this;
    $form = drupal_build_form('views_exposed_form', $form_state);
    $output = drupal_render($form);
    if (!empty($form_state['js settings'])) {
      $this->view->js_settings = $form_state['js settings'];
    }

    if (!$this->view->display_handler->displays_exposed() || (!$block && $this->view->display_handler->get_option('exposed_block'))) {
      return "";
    }
    else {
      return $output;
    }
  }

+  else {
+    $form['delete_by_config']['config_delete'] = array(
+      '#title' => t('Component name'),

I think the 'delete' context is already clear with the first key's name, so let's just 'config' for the second one.

+/**
+ * Submit handler for deletion/cancellation of future scheduled tasks.
+ */
+function rules_scheduler_cancel_submit($form, &$form_state) {
+  module_load_include('inc', 'rules_scheduler', 'rules_scheduler.rules');
+  rules_scheduler_action_cancel($form_state['values']['config_delete']);
+  drupal_set_message(t('All tasks associated with %config have been canceled.', array('%config' => $form_state['values']['config_delete'])));
+}

It seems wrong to me that we have to manually load this include file. If it doesn't work without that, this is a bug.
Also you write "cancellation" and then "canceled", I think both is valid, but we should stay with one variant only.

You may re-use rules_form_submit_rebuild() instead of rules_scheduler_filter_submit().

+function rules_scheduler_cancel_task($form, &$form_state, $task) {
+  $form = array();

We can save that $form init, it's not necessary.

+  drupal_set_message(t("Task %label has been deleted.", array('%label' => $form_state['task']['tid'])));

The tid is no label, let's use %tid just as 5 lines above.

+function rules_scheduler_views_api() {
+  return array(
+    'api' => 2.0,
+    'path' => drupal_get_path('module', 'rules_scheduler') .'/includes',
+  );

Shouldn't that be 3.0, or the alpha?

thanks.

I've took your work and did some more improvements + committed it.

* Fixed condition components to be properly executed.
* Overhauled the rules scheduler to use consistent texts in the rule scheduler UI, such that it always uses "task deletion" and never "cancel".
* Added some small UI improvements.