D22545: Add missing include QDate

[Dag Andersen]

danders closed this revision.

REPOSITORY
  R8 Calligra

REVISION DETAIL
  https://phabricator.kde.org/D22545

To: usta, #calligra:_3.0, Calligra-Devel-list, boemann
Cc: dfaure, pino, boemann, davidllewellynjones, dcaliste, ognarb, cochise, 
vandenoever

D26050: Fix build with poppler 82

[Dag Andersen]

danders added a reviewer: danders.

REPOSITORY
  R8 Calligra

REVISION DETAIL
  https://phabricator.kde.org/D26050

To: tcanabrava, #calligra:_3.0, danders
Cc: danders, rjvbb, awilcox, dcaliste, leinir, asturmlechner, ognarb, 
anthonyfieroni, Calligra-Devel-list, davidllewellynjones, cochise, vandenoever

D25034: Fix decoding of strings with wingdings/symbol characters in excel TxO records.

[Dag Andersen]

danders added a comment.


  ping

REPOSITORY
  R8 Calligra

REVISION DETAIL
  https://phabricator.kde.org/D25034

To: denexter, pvuorela, mkruisselbrink
Cc: danders, Calligra-Devel-list, davidllewellynjones, dcaliste, ognarb, 
cochise, vandenoever

D15775: Make the item background color and page cache properties available from View component

[Dag Andersen]

danders added a comment.


  ping

REPOSITORY
  R8 Calligra

REVISION DETAIL
  https://phabricator.kde.org/D15775

To: dcaliste, leinir, danders, anthonyfieroni, #calligra:_3.0
Cc: boemann, Calligra-Devel-list, davidllewellynjones, dcaliste, ognarb, 
cochise, vandenoever

D11191: Remove Plan dependencies from CMakeLists.txt

[Dag Andersen]

danders closed this revision.
Herald added a subscriber: Calligra-Devel-list.

REPOSITORY
  R8 Calligra

REVISION DETAIL
  https://phabricator.kde.org/D11191

To: kavindap, #calligra:_3.0, staniek
Cc: Calligra-Devel-list, staniek, danders, davidllewellynjones, dcaliste, 
ognarb, cochise, vandenoever

D7228: SpellCheck: Fix markup rebasing when simple edits are done (one char added)

[Dag Andersen]

danders abandoned this revision.
danders added a comment.
Herald added a subscriber: Calligra-Devel-list.


  Has been comitted

REPOSITORY
  R8 Calligra

REVISION DETAIL
  https://phabricator.kde.org/D7228

To: danders, boemann
Cc: Calligra-Devel-list, davidllewellynjones, dcaliste, ognarb, cochise, 
vandenoever

D26050: Fix build with poppler 82

[Tomaz Canabrava]

tcanabrava abandoned this revision.

REPOSITORY
  R8 Calligra

REVISION DETAIL
  https://phabricator.kde.org/D26050

To: tcanabrava, #calligra:_3.0, danders
Cc: danders, rjvbb, awilcox, dcaliste, leinir, asturmlechner, ognarb, 
anthonyfieroni, Calligra-Devel-list, davidllewellynjones, cochise, vandenoever

D26050: Fix build with poppler 82

[Dan Leinir Turthra Jensen]

leinir added a comment.


  For those who mentioned they would like part of the splitty-outy thing: 
Please pop over here and take a look and make a comment or five and let's get 
this under way - https://phabricator.kde.org/T12815 :)

REPOSITORY
  R8 Calligra

REVISION DETAIL
  https://phabricator.kde.org/D26050

To: tcanabrava, #calligra:_3.0, danders
Cc: danders, rjvbb, awilcox, dcaliste, leinir, asturmlechner, ognarb, 
anthonyfieroni, Calligra-Devel-list, davidllewellynjones, cochise, vandenoever

T12815: Create Calligra Framework by separating out applications and libraries

[Dan Leinir Turthra Jensen]

leinir created this task.
leinir added a project: Calligra: 3.0.

TASK DESCRIPTION
  As mentioned on https://phabricator.kde.org/D26050#583223 (and discussed in 
person with a number of people), the current monolithic state of the Calligra 
suite is less advantageous than it was back when it lived in subversion (where 
if you needed you could pick out bits you wanted to work on without grabbing 
the entire thing). That is to say, what used to be a positive thing, which 
lowered the barrier of entry to potential new contributors, has turned into 
something of a stumbling block, as we ask people to please clone this gigantic 
repository before they can really do much of anything. So, with that in mind...
  
  I would like to propose that we split out Calligra into several repositories, 
conceptually a set of framework repositories (for release along with KDE 
Frameworks), and a set of application repositories. As an initial suggestion, 
the list might look like so:
  
  Calligra Frameworks:
  
  - calligra-frameworks-base (what is currently in libs/ - possibly wants 
splitting further)
  - calligra-components (the Qt Quick components)
  - calligra-parts (the various KParts - this would be a fair bit of work, and 
might also want splitting out)
  - calligra-plugins (currently in plugins/)
  - calligra-extra-filters (currently in filters/)
  
  Calligra Suite (just in alphabetical order):
  
  - calligra-author (yeah, of course i have ulterior motives - i entirely 
intend to make the best creative writing on the planet out of this ;) )
  - calligra-braindump
  - calligra-gemini
  - calligra-karbon
  - calligra-sheets
  - calligra-stage
  - calligra-words
  - calligra-tools (commandline tools - one of many reasons having the 
widgetisms removed from the libraries would be good)
  
  Finally, it would be highly advantageous if, while this work is undertaken, 
we could remove all the widgetisms from the libraries
  
  This task would function as the nexus for the work, both discussion and 
tracking subtasks, and i would like to see us create these new repositories on 
Invent (to avoid a move later, and creating a clean break - that is, of course, 
unless the sysadmin team has reasons why that would be a bad idea)
  
  As a part of this, it might very well be useful for those of us intending to 
spend effort on this to all to be together somewhere at some point, for some 
high-intensity hacking. It feels to me as though this would be something where 
at least part of our handshake funds would be well spent (though perhaps that'd 
want to happen once things regarding the current world health situation have 
calmed down just a touch).
  
  I hope you like the idea - subscribe to this task, make all the words at 
eachother, and let's hammer out a plan, and then get it all sorted. We've got a 
little while until KF6, but if we can prepare beforehand... that seems like a 
worthy effort :)

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

WORKBOARD
  https://phabricator.kde.org/project/board/23/

To: leinir
Cc: Calligra-Devel-list, #calligra:_3.0, leinir, davidllewellynjones, dcaliste, 
ognarb, cochise, vandenoever

T12815: Create Calligra Framework by separating out applications and libraries

[Carl Schwan]

ognarb added a comment.


  +1 on the general idea
  
  Some remarks:
  
  - Do we want to have an abi and api stability in the Calligra frameworks? or 
do we prefer to do it like in PIM and only guaranty that all the package from a 
certain version are compatible? I think the second option is better at least at 
the beginning since we don't have many third parties users and the only one is 
using submodules with a list of patches anyway.
  
  - I don't think we need to wait for KF6 branching to split the repository. We 
could already start doing the split after the next release but more 
progressively by for example create application repository first and later 
split the rest.

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

To: ognarb
Cc: ognarb, Calligra-Devel-list, #calligra:_3.0, leinir, davidllewellynjones, 
dcaliste, cochise, vandenoever

T12815: Create Calligra Framework by separating out applications and libraries

[Nathaniel Graham]

ngraham added a comment.


  I'm always in favor of moving shared content into frameworks, but just to be 
a miserable contrarian here (so feel free to ignore me), is the size of a git 
repo really an impediment to new contributors? In my experience, the opposite 
is true, that the more git repos one needs to check out to be productive, the 
more opportunities there are for failures due to missing dependencies, code 
compiled out of order, etc. I mean, with a huge repo, you just clone it once 
and it's done. If it takes 30 seconds or a minute or two, is that really a big 
deal?

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

To: ngraham
Cc: ngraham, ognarb, Calligra-Devel-list, #calligra:_3.0, leinir, 
davidllewellynjones, dcaliste, cochise, vandenoever

Re: T12815: Create Calligra Framework by separating out applications and libraries

[René J . V . Bertin]

What's the size of the .git directory of the calligra repo these days? I seem 
to recall it was what I thought really huge already in KDE4 days. Last time I 
tried git wouldn't let you push from a clone that didn't have the full history. 
And yes, for me there's a point where I consider the value of my few and 
smallish contributions don't justify wasting "that much" disk space on what's 
literally old history.

FWIW, KDevelop moved in the opposite direction, pulled their "framework" bit 
(kdevplatform) with the other code into a single repo. Which, incidentally, 
made it harder to build only select parts (plugins), just like you cannot 
really build only a specific Calligra component against installed versions of 
the library components (last I checked).
Not that that's a necessary implication but it's a bit tricky to write a build 
system that can build against either just-build libraries or against the 
installed copies.

T12815: Create Calligra Framework by separating out applications and libraries

[Pino Toscano]

pino added a comment.


  In T12815#223360 , @rjvbb wrote:
  
  > What's the size of the .git directory of the calligra repo these days?
  
  
$ du -hcs .git/
778M.git/
  
  Few notes from a person that did few commits in the past, and current 
maintainer of Calligra in Debian:
  
  - seriously, 13 repositories? note that LO went in the opposite direction, 
and such a huge amount of sources just to get Calligra built is a hell of work
  - calligra-author is dead since Calligra 3.0... (not even in git/master)
  - calligra-braindump is sort of dead even in 2.9; "ported" to 3.0 as 
"unmaintained", hard-disabled it 3.1; better alternatives exist
  - why calligra-plugins and calligra-extra-filters? they would require all the 
other apps/libraries to build, and it would make sense to simply place the 
filters/plugins of each application together with each application
  - calligra-frameworks-base and calligra-components split? to me the latter is 
the QML version of the former, so it would make sense to make just one 
repository with the Calligra libraries
  
  In addition, a more general question: what is the goal of all of this?
  I think that splitting just for the sake of splitting is counter-productive 
(you need to invest a lot of resources to get the split parts to build and 
interact).
  
  And, who is going to contribute to Calligra? No, I'm not trying to provoke or 
anything, I'm asking seriously:
  
  - there is barely somebody that did 3.0/3.1 releases in the last 3 years
  - not many commits not related to "making it build with newer 
poppler/gcc/qt/etc"
  - barely new features...
  
  And who is going to maintain all of this?

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

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

T12815: Create Calligra Framework by separating out applications and libraries

[Camilla Boemann]

boemann added a comment.


  It is a no from me for exactly the reasons pino and ngraham bring up.
  
  Now if there was a thriving community, I'd be happy to step down  and let the 
community do this if there was a big consensus, but as it stands it will just 
kill this project even more than it already is

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

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