click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink" <sab...@gmail.com>
Subject Re: Incompatibilities
Date Mon, 15 Dec 2008 12:47:15 GMT
On Mon, Dec 15, 2008 at 12:12 PM, Demetrios Kyriakis <
demetrios.kyriakis@gmail.com> wrote:

> I think it should be a "complete" control (even if not part of Apache click
> - due to license problems).
> I think TinyMCE is the most advanced WYSIWYG right now.



Sure but first somebody needs to step up and create the control and project.
In case somebody is interested
I've added our old TinyMCE example to ClickClick.


Yes. This can be simply automated, so it shouldn't be a problem.
> On the other hand, the impact on the ease of use for your users will be
> huge.
> So the users would just take this as another good, simple and intuitive
> "convention" (like many other click already has).



Sorry to me that is more confusing. Having versions bumped without making
actual changes seems weird.

A much simpler approach is to document the external project which Click
version it depends on. You can see this very clearly
here: http://code.google.com/p/click-calendar/

Users can also use Click's get-deps task to pull down the latest version of
of click-calendar.


Also I'm not sure if it was a very efficient idea to have so many google
> projects. E.g. Wicket has one huge base: wicket-stuff that has all the
> non-apache compatible things.


Wicket-stuff is in constant flux so I don't know why you bring this up as a
good example.

Initially I wanted to integrate calendar with ClickClick but it is not
maintained currently so was too much effort. Hence
the calendar specific project was created.

Keep in mind there are only two projects: calendar and charts. And I'm not
sure how popular the chart controls are. Users
will probably only concern themselves with the calendar project.

bob

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message