D26221: Use QQC2 Dialog

2019-12-26 Thread Dan Leinir Turthra Jensen
leinir added a comment.


  That's looking pretty good, really :) Also code reduction is certainly good ;)

INLINE COMMENTS

> Dialog.qml:136
>  
> -anchors {
> -left: parent.left;
> -leftMargin: 8;
> -right: parent.right;
> -bottom: parent.bottom;
> -bottomMargin: 8;
> +QQC2.BusyIndicator {
> +running: base.enabled

Thinking this wants to be centered... or if that means things end up looking 
lop-sided, perhaps have it right-aligned? As it stands, it looks kind of... 
very heavy on the left hand side.

REPOSITORY
  R8 Calligra

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

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


D26050: Fix build with poppler 82

2019-12-26 Thread Dan Leinir Turthra Jensen
leinir added a comment.


  In D26050#583007 , @ognarb wrote:
  
  > In D26050#582981 , 
@asturmlechner wrote:
  >
  > > In D26050#578862 , 
@anthonyfieroni wrote:
  > >
  > > > Maybe we can drop 62, but not 72.
  > >
  > >
  > > If this is for master I don't see why we could keep anything pre-0.79. 
Distros already have to patch the hell out of 3.1.0 which has led to diverging 
code because several changes are conflicting. That one needs a point release to 
settle that.
  > >
  > > And meanwhile master needs a fix for 0.83 too.
  >
  >
  > What about releasing Calligra as a part of the Release Service (a release 
every 4 months with some Bugfix release between)? The latest release was almost 
2 years ago, and we have more than 500 commits in master.
  
  
  To go with this, i'm starting to think that it would perhaps not be the worst 
thing to have Calligra's engine explicitly split out, to allow it to be 
released as a proper Framework, and the applications to be applications based 
on that framework... It would seem like something that'd be worth trying to aim 
for for KF6, because while Calligra might have slowed down, that particular 
reason for Calligra's existence is still a thing, and the monolithic nature of 
the current layout of the codebase does not allow people to use it in the way 
it is intended. So... yup, going to have to spend some time considering this 
and making a formal proposal, but thought i would mention it here and get the 
idea out in the open.

REPOSITORY
  R8 Calligra

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

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


D26050: Fix build with poppler 82

2019-12-26 Thread Anthony Fieroni
anthonyfieroni added a comment.


  I'm pretty sure Krita devs think about when they split application out of 
Calligra repo and make its own copy of libs, flakes, etc. So beneficial of 
splitting libs in their own release plan will be for all applications. That 
will a huge work pretty underrated by all users.

REPOSITORY
  R8 Calligra

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

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


D26050: Fix build with poppler 82

2019-12-26 Thread Carl Schwan
ognarb added a comment.


  In D26050#583223 , @leinir wrote:
  
  > In D26050#583007 , @ognarb wrote:
  >
  > > In D26050#582981 , 
@asturmlechner wrote:
  > >
  > > > In D26050#578862 , 
@anthonyfieroni wrote:
  > > >
  > > > > Maybe we can drop 62, but not 72.
  > > >
  > > >
  > > > If this is for master I don't see why we could keep anything pre-0.79. 
Distros already have to patch the hell out of 3.1.0 which has led to diverging 
code because several changes are conflicting. That one needs a point release to 
settle that.
  > > >
  > > > And meanwhile master needs a fix for 0.83 too.
  > >
  > >
  > > What about releasing Calligra as a part of the Release Service (a release 
every 4 months with some Bugfix release between)? The latest release was almost 
2 years ago, and we have more than 500 commits in master.
  >
  >
  > To go with this, i'm starting to think that it would perhaps not be the 
worst thing to have Calligra's engine explicitly split out, to allow it to be 
released as a proper Framework, and the applications to be applications based 
on that framework... It would seem like something that'd be worth trying to aim 
for for KF6, because while Calligra might have slowed down, that particular 
reason for Calligra's existence is still a thing, and the monolithic nature of 
the current layout of the codebase does not allow people to use it in the way 
it is intended. So... yup, going to have to spend some time considering this 
and making a formal proposal, but thought i would mention it here and get the 
idea out in the open.
  
  
  +1 and I'm willing to help :)

REPOSITORY
  R8 Calligra

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

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