Provide color settings page

Now without whitespaces ;)

Argh.. what is happening to me :(

Another try...

Woow thnx for the testing. Didn't expect someone would use this so soon :). Did you try the css ordening to?

Reviewed my own code.

+++ b/fullcalendar_colors/fullcalendar_colors.moduleundefined
@@ -67,6 +67,17 @@
+    'weight' => 2,
+  );

Hmmm, probably we always want the setting to be last, maybe we should give this a higher number. 20 or something like that.

+++ b/fullcalendar_colors/fullcalendar_colors.moduleundefined
@@ -146,3 +167,129 @@
+    // Filter modules that didn't provide any css
+    $modules = array_intersect_key($modules, $css);
+  }

This maybe looks odd but this was needed to make it work with empty calendars BEFORE the refactoring.

Im not sure if this is needed anymore. Will look at it in the next days.

+++ b/fullcalendar_colors/includes/fullcalendar_colors.admin.incundefined
@@ -175,6 +175,145 @@
+  $form['info'] = array(
+    '#type' => 'item',

Probably needs a better form id

+++ b/fullcalendar_colors/includes/fullcalendar_colors.admin.incundefined
@@ -175,6 +175,145 @@
+  foreach (module_implements($hook) as $i => $module) {
+    $modules[$module] = variable_get('fullcalendar_color_weight_' . $module, $i);

I use the $i to give every row an unique weight as default.

+++ b/fullcalendar_colors/includes/fullcalendar_colors.admin.incundefined
@@ -175,6 +175,145 @@
+  if ($form_state['values']['default_color_enabled']) {
+    variable_set('fullcalendar_color_default_color', $form_state['values']['default_color_input']);
+    variable_set('fullcalendar_color_default_color_enabled', TRUE);
+  }
+  else
+    variable_set('fullcalendar_color_default_color_enabled', FALSE);
+

Is there a better way to handle these variable set instructions

+++ b/fullcalendar_colors/includes/fullcalendar_colors.admin.incundefined
@@ -175,6 +175,145 @@
+    $row[] = check_plain($form['modules'][$module]['#name']);
+    $row[] = drupal_render($form['modules'][$module]['weight']);

This is not user input, probably doesn't need a checkplain

+++ b/fullcalendar_colors/includes/fullcalendar_colors.admin.incundefined
@@ -175,6 +175,145 @@
+  $output .= drupal_render($form['default_color']);
+  $output .= drupal_render($form['default_color_enabled']);
+  $output .= drupal_render($form['default_color_input']);
+  $output .= drupal_render($form['info']);

If we put this in a fieldset in the form we can render it with one line I think...

+++ b/fullcalendar_colors/includes/fullcalendar_colors.admin.incundefined
@@ -175,6 +175,145 @@
+  $output .= drupal_render($form['form_build_id']);
+  $output .= drupal_render($form['form_token']);
+  $output .= drupal_render($form['form_id']);

I needed this to make the form work. Do you know why exactly?

Powered by Dreditor.

New version rdy for a review

The whitespace is an illusion...

I don't like the table on top of the page.

1) its ugly
2) default color will be the primary use case (I think)

I thought about this for a few hours and I can't see the added value of a seperate module.
To make the module generic you have to

1) Add classnames yourself into the code (or use an alrdy existing classname/selector)
2) build the css string yourself
3) provide the colours you wish to have as background/textcolour yourself
4) the modules implementing this will have to take the responsabilty to add the css in the right order themselves

So the color module *could* provide the folowing functions

- add_colors($selector, $colors (array) )

=> $selector a random selector or multiple selectors seperated by a ','. For example: 'article a, article a.active'
=> $colors an array, matching types of colour with a color

For example:

$colors = array(
'background' ==> black,
'text' ==> white
'border' ==> green
'...'
)

- RemoveSelector($selector) (==> $selector must be unique!)

- RemoveSelectors($moduleName)
==> For example we would like to remove all the colors made by fullcalendar_colors

This means we have to make a custom database table
- selector name ==> unique
- a column for each color type (background, text, ...) ==> Can you store an array in a database? Would be easier and extensible.
- a module name (defaults to "colors") ==> so we can remove colours of specific modules at once

Colors UI?
- This could be like my colors extension module

Selector | background | text | ... | operations
------------------------------------------------------------------
articla a | white | black | .... | remove
page a | green | yellow | ..... | remove

Conclusion?
Not sure yet... Brain freeze...

We are discussing if we can make a general coloring module. And fullcalendar_colors would build on top of that.
The fullcalendar colors extension project will probably be renamed to fullcalendar colors classnames in the end.
It will be a seperate module.

We are still brainstorming but I won't drop any features I added.

I think this is all we need. Based on the ctools branch.