On 2012-04-23 18:25, Cunningham, Robert wrote:
I'm evaluating Trac vs. Fossil for use within our small engineering
department (2 CEs, 2 EEs, 2 MEs). I have some experience with Trac
and
none at all with Fossil (I've been using SVN + Bugzilla for way too
long). We need version control, bug tracking and documentation tools,
and getting them rolled into a single integrated system is highly
desired, even if compromises must be made. I have both systems
running
in parallel, and the other engineers are playing with each as time
permits.
So far, Fossil is winning quite handily on all the key technical
features and issues we care about. But usability issues, especially
for non-software folks, provide some stumbling blocks.
One feature many enjoy is the side-by-side wiki editing capability of
Trac (http://trac.edgewall.org/wiki/TracWiki [1]), especially those
who have little or no experience with wiki markup or HTML, or folks
like me who have used way too many wiki markup systems and keeps
getting them confused. The side-by-side approach provides a very
nice,
possibly ideal, compromise between full (and heavy) WYSIWYG editing
vs. the tedious edit/preview cycle.
Is side-by-side wiki editing available in Fossil? Ideally, this mode
would be available wherever any kind of markup is allowed to be
entered, such as within tickets.
FWIW, while searching for other implementations of similar
capabilities I stumbled across Wiky
(http://goessner.net/articles/wiky/ [2]), which could permit such a
feature to be implemented using only client-side code. (Not that
that's an issue for Fossil, where the entire local UI server is
"client side"!)
TIA,
-BobC
Links:
------
[1] http://trac.edgewall.org/wiki/TracWiki
[2] http://goessner.net/articles/wiky/
Because i'm a procrastinator, I implemented it for wiki.
It took me a while to find out why firefox XmlHttpRequest post
parameters did not reach the preview routine.
it turns out I say Content-Type: application/x-www-form-urlencoded
and Firefox says Content-Type: application/x-www-form-urlencoded;
charset: UTF-8;
The cgi routine only picks up parameters for
application/x-www-form-urlencoded.
I found that Chrome does it correct. I wanted to touch as little as
possible and didn't pursue to get it working with Firefox. (and Firefox
has this behavior since 3.5!)
Kind of funny to see "magical" the preview appearing on the right.
However for large documents, Like compillingOnWindows, I'm not
convinced of the benefits.
I added something like 150 lines to wiki.c and more then hundred are
javascript. In order to get it working with more browsers I assume that
the number will raise significant. The question is does someone wants to
have a lot of javascript in the files that have wiki syntax editing in
order to have side by side editing?
Does anyone wants this in a branch? I'm not sure if I would put more
effort in it, So it will be depending on other persons.
I wonder how it works out with a busy server and/or slow network!
--
Rene
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
