leinir added a comment.
//furiously attempts to put the worms back in the can// - Oh dear! ;) Right! That's a really good bunch of discussion up there (and very civil, thanks all!), and what we can read from this is that no, we really, really(, no seriously, for real really) don't want to split up the repositories, as that raises an already high barrier of entry even higher without any worthy gain. The other bits of this are still valid, though, from what i see, so... with that in mind, it sounds like what we might want to try and do is perhaps more a bit of code reorganisation and some refactoring in certain places... - Get rid of the widget requirements in the core libraries themselves. We can enforce this without much trouble at link time (like @dcaliste suggests). Having done this somewhat hackishly during the initial work for Sailfish, i realise this is not a simple task, but i firmly believe it's a worthwhile one. - Those libraries which really /require/ widgets (on account of being UI for some operation or another) can do so, but will want to be described as such in an explicit fashion (perhaps by being given a suitable name). We've already got a bunch of that done (widgets and widgetutils), but we still managed to have some of the UI sneak in where it perhaps wants not to be in some places. - Documentation - as @davidllewellynjones says, we've got a bunch already, and it really isn't terrible at all - but that said more could (and should) be done (also, water is wet, circles are round ;) ). Especially we've got a bit of a disconnect between what's on techbase and what's on api.kde.org, and if someone wants to jump in somewhere, that'd probably be a nice place to start (for example, there's rundowns of some of the codebase on techbase pointing to details on api.kde.org, which likely wants to be in the code instead, so we can avoid links randomly dying on us - techbase landing page would remain, but point to api.kde.org for that information). Suddenly a much more contained effort, and one which... well, doesn't require quite so much lock-down coordination perhaps On a personal note, I'm really glad to see everybody sounding so keen on Calligra in general, too, it's heartening to see more than just nostalgia :D PS: I still personally intend to attempt to produce a new Author (the reason it was removed was because it quite literally was just a copy of Words, with nothing additional or new, since all the work had happened in filters or in Words itself, and so having that target in the source tree essentially served no purpose), but i am thinking this could be a useful test for an external application which makes use of the Calligra libraries, without being Calligra itself. Those who have used Scrivener will be aware of some of where i intend to go with that application, and also why that would not fit very well into a generic word processor :) TASK DETAIL https://phabricator.kde.org/T12815 To: leinir Cc: davidllewellynjones, ndavis, jtamate, rempt, anthonyfieroni, dcaliste, boemann, pino, rjvbb, ngraham, ognarb, Calligra-Devel-list, #calligra:_3.0, leinir, cochise, vandenoever
