<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 November 2015 at 15:25, Jos van den Oever <span dir="ltr"><<a href="mailto:jos.van.den.oever@kogmbh.com" target="_blank">jos.van.den.oever@kogmbh.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 11/06/2015 09:30 AM, Jaroslaw Staniek wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 6 November 2015 at 07:23, Jos van den Oever <<a href="mailto:jos.van.den.oever@kogmbh.com" target="_blank">jos.van.den.oever@kogmbh.com</a><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
wrote:<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 07/28/2015 07:33 PM, Jaroslaw Staniek wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi!<br>
My use of docbook failed due to complexity. Also userbase-based docs<br>
(at least for Kexi, for which a finished book could be easily over 300<br>
pages) are far from perfect and not too actively maintained. No<br>
surprise as it's too much of work if it's used "just" by KDE.<br>
<br>
Still I am grateful for tools that we have now!<br>
<br>
In the meantime I just installed asciidoc.[1] Some projects like git<br>
use it for all documentation needs. There's support for localization<br>
via po4a.<br>
There's even more than one implementation.<br>
<br>
Anyone considered asciidoc as a docbook replacement? It would be good<br>
to discuss this and see how it fits for our needs.<br>
<br>
[1] <a href="http://www.methods.co.nz/asciidoc/" rel="noreferrer" target="_blank">http://www.methods.co.nz/asciidoc/</a><br>
<br>
<br>
</blockquote>
Calligra comes with two word processors: Words and Author. Those have the<br>
file format ODF. ODF has all the features needed for documentation. Using<br>
your own tools for documentation is a good way of dogfooding. Certainly<br>
Calligra Words is good enough for the developers to use themselves. It is<br>
good to show confidence in your own tools by using them.<br>
<br>
With a nice styles.xml and sane style names, writing the ODF with Calligra<br>
or any other editor should work fine. You could use the XML serialization<br>
of ODF. With some XSLT that could then be conver<br>
<br>
ted to Docbook for use in the KDE toolchain.<br>
<br>
I'm developing a tool that cleans up ODF files so the diffs in git are<br>
small. The ODF TC is using this tool for comming clean versions of the<br>
specification in the source control system.<br>
<br>
<a href="https://gitlab.com/odfplugfest/odfhistory/" rel="noreferrer" target="_blank">https://gitlab.com/odfplugfest/odfhistory/</a><br>
<br>
Using Calligra Words for documentation will really improve Calligra Words<br>
and the documentation.<br>
<br>
<br>
</blockquote>
Jos<br>
I share the sentiment. Yes, gitbook competes with what Author would be.<br>
<br>
But I see the same category there are following observation:<br>
<br>
- we, technical people are still using command line and so frequently<br>
non-GUI editors instead of Kate, despite the fact that using Kate more can<br>
improve it<br>
<br>
- we, technical people do versioning via git, mostly because it's close to<br>
command line and text content to, we don't use zip files to despite the<br>
fact that doing that would improve, say, Ark<br>
<br>
- we, technical people use Phabricator for light project management instead<br>
of Calligra Plan, despite the fact that using Plan would improve it<br>
<br>
- same for TODO lists: I've seen dozens of command line tools for that,<br>
many used by KDE people, despite the fact that using Kontact would improve<br>
it<br>
<br>
- did I mention KMail?<br>
</blockquote>
<br></div></div>
I use KMail. :-)<span class=""><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So for me that's: use best tools available for the job. And that there's<br>
some fundamental difference between the approaches that drag people to less<br>
'integrated' tools.<br>
<br>
Technical limitation of XML diffs is also somewhat important, even if we<br>
use fodf. I am looking forward to try your results. And I'd like to seem,<br>
say LO's help converted to the format and developed this way. Someone<br>
should convince me that LO would depend on Calligra for own document<br>
tooling needs.<br>
<br>
I think Calligra-based solution shall be much better to balance the issue<br>
with difficult deployment (on Linux statistically people have no access to<br>
current Calligra, on Windows the Docbook dependencies are just a nightmare<br>
to have installed and maintained -- not many users of that, end even if,<br>
the "KDE" flavour is used just by the fraction of KDE devs, while competing<br>
solutions). If it's just "like" plain asciidoc or gitbook-like solutions,<br>
there's no market IMHO. BTW, <a href="http://gitbook.com" rel="noreferrer" target="_blank">gitbook.com</a> has some business model, while we<br>
depend on donations shared with entire KDE.<br>
<br>
Summing up for now: I don't see anyone who cares until there's excellent<br>
solution. KDE's own needs form too small 'market' and even within KDE<br>
there's not much interest from what I observe.<br>
<br>
One solution could be: make our apps more agile and command-line friendly.<br>
This is huge non-programming task.<br>
</blockquote>
<br></span>
It is not just about the user interface but also the file format.<br>
<br>
I saw a very interesting and entertaining presentation today about exactly the tendency of developers to use custom markups for specific simplified purposes instead of using a rich xml format.<br>
<a href="http://ndw.github.io/presentations-2015-xml-amsterdam/#/" rel="noreferrer" target="_blank">http://ndw.github.io/presentations-2015-xml-amsterdam/#/</a><br>
It also mention asciidoc and docbook.<div class=""><div class="h5"><br>
<br></div></div></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Thanks Jos.</div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">Yes, That's a tendency derived from our preference of working with plain text.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">The presentation you linked is close to plain-text too...<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">And plain text is both about document formats and about specific architecture of interaction.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">On top of that there's departure from classical files or filesystems. Even git helps us to think about filesystem in a different way than we used to think 10 years ago.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br>Idea: Perhaps it's possible to let users to browse into the structure of ODF (or ODF-compatible) document just like the git repos are not able to represent complex documents/books. Why wouldn't it be possible for Calligra core apps to open a versioned 'folder' having content.xml (or equivalent), styles, images, inside?<br><br>We're working hard to support all the miracles of ODF. But being mostly there I see the competing "preferred" solutions are far less featureful than ODF, yet they are are competitive. This suggests the lightness of the format is the inherent property of these other solutions. I think it all started with wikis years ago. Can we expect a subset of "ODF light" to be officially defined somewhere?<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br></div></div></div>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>