T12815: Create Calligra Framework by separating out applications and libraries

[David Llewellyn-Jones]

davidllewellynjones added a comment.


  As a newcomer, and only occasional contributor, my experience of getting the 
build up and running is that it's already a daunting process, made tractable 
only because the instructions  
are very good. Anything that simplifies these instructions is good, anything 
that complicates them is bad.
  
  If I'm honest, having everything in one repository probably made things 
simpler. I'm sure separate repos could be made easy too (e.g. using 
submodules), but also introduces more scope for errors that are difficult for 
an occasional contributor (i.e. me) to solve.
  
  In T12815#223419 , @dcaliste wrote:
  
  > But what I like in the proposition of @leinir is the target to separate the 
"engine" from the UI (_i.e._ the widgetery). As an example (hopefully not 
outdated), the "find" classes, the one to search and replace, are deeply liked 
to the widgets that control them. It makes it impossible to reuse these class 
in a UI different from the original one.
  
  
  Having said all that above, as a developer for Sailfish OS (but speaking 
personally), I would completely second @dcaliste's point. Whatever the delivery 
structure, better decoupling between components would make Calligra more 
flexible and usable in other contexts. The split between the chrome and the 
document rendering is a very clear case, and if splitting into repos helps 
reinforce this, then I'd support it.

TASK DETAIL
  https://phabricator.kde.org/T12815

To: davidllewellynjones
Cc: davidllewellynjones, ndavis, jtamate, rempt, anthonyfieroni, dcaliste, 
boemann, pino, rjvbb, ngraham, ognarb, Calligra-Devel-list, #calligra:_3.0, 
leinir, cochise, vandenoever

T12815: Create Calligra Framework by separating out applications and libraries

[Dan Leinir Turthra Jensen]

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