[development] should tinymce get a new maintainer tinymce

[Kevin Reynen]

Is everyone is aware that drupal-id was maintaining TinyMCE plus
(http://drupal.org/project/tinymce_plus) before taking over the
TinyMCE module?

Is the suggestion to move drupal-id's current module back to TinyMCE
plus and revert TinyMCE to the patched version of 4.7?

It seems like the project was already forked once and making drupal-id
the maintainer of the primary module was an attempt to merge these
efforts.

Learning to edit the theme .js files may push less technical users
beyond their comfort zone, but it is really the TinyMCE way of doing
things.   There are 3 very usable themes included for people who just
can't edit comma separated lists.  For those who want to learn to
modify their .js themes, there is community that is much bigger than
just the TinyMCE module users who help support this.  Drupal users
make up a small part of TinyMCE users.

If you really can't use TinyMCE without a GUI toolbar designer,
wouldn't the proper place to do that be as a stand alone tool that
output theme.js files that any TinyMCE user could use?  Write that in
javascript and release it as a TinyMCE tool.  Users could design their
toolbars and save that .js file to their
/modules/tinymce/includes/themes/.  The admin interface for the
TinyMCE module would simply allow users to link their theme .js files
with their roles (a Drupal specific feature).

Correct me if I'm wrong, but didn't the 4.7 (and patched 5) button
configuration bypass the .js theme files?  Shouldn't Drupal
development respect the way other frameworks want to handle their
configuration?

I have neither been involved with Drupal long enough nor been active
enough to deserve a vote, but if I'd had one it would be to "stay the
course" drupal-id started regardless of who the maintainer is.

- Kevin

On 2/5/07, Robert Douglass <rob at robshouse.net> wrote:
> Boris Mann wrote:
> > In some ways, the 5.0 version is a "fork" of the 4.7 code. The nice
> > thing is that our current development method actually enables this. A
> > suggestion has been to have the 4.7 "evolution" be the 5.0--1.0 tag,
> > with the brand new code being 5.0--2.0
> >
>
> In fact, this is the responsible pattern to follow. Give folks an
> upgrade path that doesn't change the way things work, deprecate it if
> necessary, and continue development on the branch. Merlinofchaos has
> basically done just this with Panels, and the world is a happy place.
>