T12815: Create Calligra Framework by separating out applications and libraries

marcboocha added a comment. Since it is a graphics related program unlike rest of the suite, i was thinking karbon could be split into its own repo. Similar to krita. TASK DETAIL https://phabricator.kde.org/T12815 To: marcboocha Cc: marcboocha, danders, davidllewellynjones, ndavis, jtamate

T12815: Create Calligra Framework by separating out applications and libraries

anthonyfieroni added a comment. In T12815#238382 , @marcboocha wrote: > Just wondering, is there any use of karbon inside the suite? What kind of use? TASK DETAIL https://phabricator.kde.org/T12815 To: anthonyfieroni Cc: marcboocha, d

T12815: Create Calligra Framework by separating out applications and libraries

marcboocha added a comment. Just wondering, is there any use of karbon inside the suite? Also the stuff used by okular could be split out? TASK DETAIL https://phabricator.kde.org/T12815 To: marcboocha Cc: marcboocha, danders, davidllewellynjones, ndavis, jtamate, rempt, anthonyfieroni,

T12815: Create Calligra Framework by separating out applications and libraries

danders added a comment. I think where leinir has landed is more doable than a frameworks. Also if compiletime is a big hurdle, I see a couple of things that can be done: - Remove pigment, see T5738 . - Make more finegrained productsets. Pt the on

T12815: Create Calligra Framework by separating out applications and libraries

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 t

T12815: Create Calligra Framework by separating out applications and libraries

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

T12815: Create Calligra Framework by separating out applications and libraries

rjvbb added a comment. > I sometimes find myself feeling this way about Frameworks too. A recent experience at a hackathon where I helped 8 students set up complete development environments from scratch reinforced this viewpoint. Not that I'm seriously recommending re-merging the framework

T12815: Create Calligra Framework by separating out applications and libraries

jtamate added a comment. As I have some free time due to the virus and I'm trying to get up to date. In the SQL word there is the notion of tables, queries and views, where a view can show de values of several tables (combined, filtered or raw). Do you know if there is something simi

T12815: Create Calligra Framework by separating out applications and libraries

ngraham added a comment. In T12815#223428 , @rempt wrote: > As an aside, I think splitting up kdepim into so many repositories was a huge mistake. Listening to David Faure at the onboarding sprint only confirmed that opinion. Having to work on h

T12815: Create Calligra Framework by separating out applications and libraries

rjvbb added a comment. > As an aside, I think splitting up kdepim into so many repositories was a huge mistake. Ah yes, that was definitely one of the reasons why I never updated my kdepim4 packaging. That said, I also appreciate the fact that the few apps I use that depend on kdepim

T12815: Create Calligra Framework by separating out applications and libraries

rempt added a comment. In T12815#223424 , @anthonyfieroni wrote: > @leinir Or you want Krita to returns back to Calligra framework? That's not going to happen... We're happy hacking out all the flexibility from the libraries that was onl

T12815: Create Calligra Framework by separating out applications and libraries

anthonyfieroni added a comment. @leinir correct me if i'm wrong, but this can be beneficial if some of Calligra Suite want to have different release circle, like Krita before. Or you want Krita to returns back to Calligra framework? TASK DETAIL https://phabricator.kde.org/T12815 To: antho

T12815: Create Calligra Framework by separating out applications and libraries

dcaliste added a comment. As a nobody, my opinion on the rightfullness to split or not the repository is of no interest. 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"

T12815: Create Calligra Framework by separating out applications and libraries

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 a

T12815: Create Calligra Framework by separating out applications and libraries

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

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

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 o

T12815: Create Calligra Framework by separating out applications and libraries

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 o

T12815: Create Calligra Framework by separating out applications and libraries

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 bett

T12815: Create Calligra Framework by separating out applications and libraries

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