Re: Krita donation proposal

2021-11-16 Thread Camilla Boemann
I'm fine with Krita and Plan taking everything. The money needs to work and not 
gather dust. And Krita seems a worthy candidate. If the donor agrees I don't 
know, but I would certainly support it.

Camilla Boemann
Calligra Words maintainer (by name mostly)

On 16/11/2021 11.35.31, Halla Rempt  wrote:
Hi,

The KDE e.V. board still sits on this money, since there's almost nothing 
happening in calligra land. Of everything that used to be Calligra, only Plan 
and Krita show activity. Kexi also seems dormant. But the board needs to spend 
that money, so what should we do?

Not that I want to be greedy, but if Calligra cannot spend it on anything, I'm 
find with taking a larger share for Krita... And is there a way to spend it on 
Plan?

Cheers,

Halla Rempt

On woensdag 17 oktober 2018 10:35:30 CET Dan Leinir Turthra Jensen wrote:
> Yes, i agree with Dag. Handshake's donation does seem to have been a
> historical congratulations type thing more than anything else, so certainly
> Krita deserves a chunk of this.
>
> On Wednesday, 17 October 2018 09:31:54 BST Dag wrote:
> > Imho, a good idea. Does not seem krita gets anything directly, maybe
> > because it is considdered part of calligra.
> >
> > ---
> > Cheers,
> >
> > Dag
> >
> > Jaroslaw Staniek skrev den 2018-10-16 18:06:
> > > Dear Calligra contributors,
> > > Congratulations again on the donation [1] and big thanks to the
> > > Handshake Foundation for recognizing Calligra!
> > >
> > > tl;dr: I'd like to propose that 10% of the sum goes to support Krita.
> > >
> > > Introduction
> > >
> > > As person helping with completing the donation process I'd like to
> > > repeat the fact that Calligra was recognized by the Handshake
> > > Foundation as an organization having specific achievements in the FOSS
> > > world. The Foundation decided to offer the donation unconditionally
> > > and independently of the KDE's one.
> > >
> > > Unlike other "Office" projects Calligra has no dedicated foundation so
> > > the solution was to join KDE e.V. on the task around the bookkeeping
> > > and related matters and to ensure transparency. It also felt most
> > > natural since we're KDE. So there was no decision of the KDE board or
> > > KDE community to split the one fund to Calligra and the rest of KDE,
> > > there are two funds.
> > >
> > > Details
> > >
> > > Now that we're around next, harder step, I'd like to share my position
> > > that addresses possible question of the contributors and fans: what
> > > with supporting Krita?
> > >
> > > Based on what I learned from the donor the funding is based on
> > > recognition for the *entire* history of KOffice/Calligra so Krita
> > > being important member of our family, not only can but *should* be
> > > included i nthe support. Krita has been on the same level of
> > > organization as other Calligra applications until 2.9 version [2].
> > > There were 10 visible Calligra apps, not counting variations of apps
> > > like mobile or Active and the Office Engine. So I'd like to propose
> > > that 10% of the sum goes to support Krita, formally the Krita
> > > Foundation.
> > >
> > > Assertions
> > >
> > > This is my idea, without any requests from the Krita side. And for my
> > > understanding the idea does not limit possibility of Krita or current
> > > Calligra to benefit from the "KDE" donation, especially indirectly,
> > > e.g. through the shared infrastructure and common development
> > > programs.
> > >
> > > Common sense suggest me reasonable requirement for supporting Calligra
> > > sub-projects: they needs to be active (have relatively recent
> > > releases) with potential to growth, and activity should be
> > > sufficiently independent of existence of the attractive funding that
> > > was received. I think Krita meets these requirements.
> > >
> > > [1]
> > > https://dot.kde.org/2018/10/15/kde-ev-receives-sizeable-donation-handshake
> > > -foundation [2] https://www.calligra.org/krita
> > > --
> > >
> > > regards, Jaroslaw Staniek
> > >
> > > KDE:
> > > : A world-wide network of software engineers, artists, writers,
> > >
> > > translators
> > >
> > > : and facilitators committed to Free Software development -
> > >
> > > http://kde.org
> > >
> > > KEXI:
> > > : A visual database apps builder - http://calligra.org/kexi
> > > :
> > > http://twitter.com/kexi_project https://facebook.com/kexi.project
> > >
> > > Qt Certified Specialist:
> > > : http://www.linkedin.com/in/jstaniek
>
>
>






Re: Clazy fixes and CI…

2021-02-13 Thread Camilla Boemann
I'd say just do it.

The code i work on at work uses the new style too, and apart from a few places 
with overloaded signals or slots it is really easy to work with

On 13/02/2021 14.43.59, Pierre  wrote:
Hi

In order to rejuvenate a bit some parts of the code base, I am looking into
Clazy, especially the old-style connect fixit. In several projects, switching
away from these made the application more reliable, with issues being catched
at build time instead of run time.
Do you see any reason not to do that? I plan to do it on words and its libs
first since that's what I will test the most, but if you want I can do it on
the whole project.
After that cleanup is done, I will start looking into setting up a CI and
running the unit tests we have automatically in gitlab. I think this could
lower the entry barrier for new/junior developers… If somebody else already
tried/did that, any feedback/hint/help is welcome obviously.

Cheers

Pierre


Re: Next release schedule/plans

2021-02-13 Thread Camilla Boemann
It has always been the rule that minor changes that you feel confident about is 
just pushed.

Changes to architecture or user experience should be put up for review, and 
possibly even discussion.
We have never required complete approval, but should carefully listen to 
objections and not do changes before there is at least acceptance.

You are co-maintainer of Words already so that gives you a big voice in how 
things should go

As for my own co-maintainership - I'm willing to give it up if you like as I 
will probably not have time to do actual coding. On the other hand I do 
continue to monitor as long as you don't ask me to step down

Camilla.

On 13/02/2021 11.20.55, Pierre  wrote:
Hi

Since the tickets and things I want to do may have varying duration, I would
like to know if there is any schedule/plan set for the next major release.
Depending on the timeframe, I could switch from small tickets to bigger ones
more easily.
On a side note, is there any rule regarding the merge requests in the project?
I'm not used to this kind of tool outside company projects where there are
rules like 'another contributor approval is needed' or 'every single change
must go through a merge request'. For the small fixes I am pushing so far,
asking for a review may be overkill…

Regards

Pierre

Re: Minimum dependency versions

2021-02-10 Thread Camilla Boemann
I agree let's move ahead. We can't be defined by what Jolla does and needs

However let's only do it if development is going to pick up. No need to annoy 
Jolla and then for everything to stall.

On 10/02/2021 20.39.59, Carl Schwan  wrote:
Le mercredi, février 10, 2021 7:45 PM, Pierre a écrit :

> On Wednesday, February 10, 2021 9:30:43 AM CET Adam Pigg wrote:
>
> > I wish!!! ... try qt 5.6!
> > On Wed, 10 Feb 2021 at 08:14, Halla Rempt b...@valdyas.org wrote:
> >
> > > On Wednesday, 10 February 2021 08:44:54 CET Pierre wrote:
> > >
> > > > Is there a lot of people still trying to build Calligra with Qt 5.3 or
> > > > KF5
> > > > 5.7.0 ? These are years old, and I guess building Calligra with them has
> > > > been untested for some time.
> > >
> > > I think that the Jolla people still build the documents application with
> > > Qt 5.9.
> > > --
> > > https://www.krita.org
>
> I created this MR then :
> https://invent.kde.org/office/calligra/-/merge_requests/10
>
> At least it's no longer Qt 5.3 / KF 5.7, and a bunch of deprecated stuff is
> cleaned up (I built locally disabling deprecated Qt APIs).
>
> But Jolla decided to stay at Qt 5.6 out of fear from LGPLv3, as far as I
> understand. Does it means Calligra would have to be stuck in an untested
> setup? I no longer have a Jolla phone, do they update from Calligra
> frequently? And is there a lot of people still building with Qt 5.6 and
> testing so we are sure there is no regressions there?

Hi,

Your MR looks good to me. Concerning the minimum version requirement, I worked
a bit last year to remove a lot of warnings and I was blocked to move further
by the minimum requirements.

Personally, I'm not sure if it is worth continuing to support Qt 5.6. Calligra 
can't
continue to use on Qt 5.6 as the minimum required version for years when we are
moving to Qt 6 in a timespan of 1 or 2 years with the rest of KDE. Also as
you said I'm not sure anyone is testing regressions and the Gemini QML code
is definitively using Qt 5.12 only code. Jolla needs to move forwards with their
LGPLv3 problem or they will end up obsolete compared to the rest of the Qt 
world.

I would propose moving all the way to Qt 5.12 or even 5.15, so we can start
fixing deprecations in time for Qt6. And maybe in the second step, we should
consider moving to C++17 too.

Regards,
Carl




Re: Minimum dependency versions

2021-02-10 Thread Camilla Boemann
Hi Pierre

Long time no see indeed

I myself is only reading mails and answering some reviews now and then.

Camilla

On 10/02/2021 08.45.13, Pierre  wrote:
Hello friends

Long time no see, how are you all?
Life and health have kept me away from this project for too long, but as you
may have seen from the merge requests in gitlab I am trying to come back a
bit.
I am looking at the build warnings right now, and a lot of them are about
deprecations, that's easy to fix so I will look into them (this may also ease
future Qt6 transition, who knows). But the current minimum version
requirements from CMakeLists.txt are a bit low.
Is there a lot of people still trying to build Calligra with Qt 5.3 or KF5
5.7.0 ? These are years old, and I guess building Calligra with them has been
untested for some time.
May I suggest updating to Qt 5.12 / KF5 5.60 ? This would be a first step, and
will make it easier to fix deprecation warnings in a way that should work with
all supported Qt and KF5 versions.

Regards

Pierre Ducroquet

D15111: [KoUnit] Let's show pixel units

2020-05-16 Thread Camilla Boemann
boemann added a comment.


  All painting of documents is done in points
  
  the purpose of KoUnit is to allow the user to specify some size in any unit 
so that it internally can be converted to points.
  
  Pixels are very special in that they are not a unit at all, but for special 
cases like karbon and krita it makes sense to allow such specification anyway, 
since the output is a bitmap. where a pixel is a very real unit.
  
  The trouble with allowing pixels to be specified in the general sense is that 
the ppi is dependent of zoom and of display. This will vary from user to user 
and in the case of zoom even as the user zooms in and out.
  
  So yes please make a karbon only solution, but even in karbon you should 
allow the user to specify the target ppi. For Icons you may get away with an 
assumption of 96 ppi but even that is really wrong, it just happens to work as 
most have it wrong the same way.
  
  But such assumptions will break any kind of real workflow for the other 
applications so it is very important not to make such a mistake.

REPOSITORY
  R8 Calligra

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

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


D15111: [KoUnit] Let's show pixel units

2020-05-16 Thread Camilla Boemann
boemann added a comment.


  Even for line thickness it doesn't make sense to enable it in general. the 
image will change if you zoom in and out.
  
  If you want to have line thickness expressed as pixels based on a destination 
rendering, then you make a separate dialog, where you (in this specific 
instance) allow the user to specify number of pixels. Then you convert the 
pixel thickness into a physical thickness based on the target rendering scale.
  
  If you do that then all other apps will still work, with no ill effects and 
karbon users can specify it in karbon.
  
  But you do NOT do it in a general way for all apps. Only karbon does 
rendering to a specific bitmap. All other apps are just showing a document at a 
zoom level - in this case you definitely don't what to have something display 
relative.

REPOSITORY
  R8 Calligra

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

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


D15111: [KoUnit] Let's show pixel units

2020-05-15 Thread Camilla Boemann
boemann added a comment.


  Nothing prevents Karbon from having a m_pixelUnit with ppi collected from a 
widget for user control
  
  and the use that unit like inkscape does.
  
  But what this patch does is enable it in general with an arbitrary chosen ppi 
value
  
  Why not measure in apples too - it will make as much sense ..

REPOSITORY
  R8 Calligra

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

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


D15111: [KoUnit] Let's show pixel units

2020-05-15 Thread Camilla Boemann
boemann added a comment.


  And that is why this proposal should be rejected as is
  
  pixels is not a unit unless assigned a ppi on a case by case basis
  
  and thus it needs to be something requested and not EVER something that is 
always available !

REPOSITORY
  R8 Calligra

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

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


D29242: WIP: redesign sidebar

2020-04-28 Thread Camilla Boemann
boemann added a comment.


  Well you are definitely in the right class to make such changes.
  
  The thing is the current  code was made to adopt to many different user 
wishes - so the user could choose
  
  What you are doing is to throw all that away - would it be impossible to have 
this new way as a mode so we don't throw away the old but enhance it with 
something new.
  
  I don't mind if the new mode becomes default

REPOSITORY
  R8 Calligra

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

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


D29242: WIP: redesign sidebar

2020-04-27 Thread Camilla Boemann
boemann added a reviewer: boemann.

REPOSITORY
  R8 Calligra

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

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


D29242: WIP: redesign sidebar

2020-04-27 Thread Camilla Boemann
boemann added a comment.


  My immidiate reaction is no.
  
  Do you mind sharing a screenshot / drawing of what the end goal is here ?

REPOSITORY
  R8 Calligra

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

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


T12815: Create Calligra Framework by separating out applications and libraries

2020-03-13 Thread 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


D25254: Remove flow, not needed since karbon can do it all

2019-11-11 Thread Camilla Boemann
boemann added a comment.


  To be honest I kind of liked the idea of a dedicated flow drawing tool and a 
dedicated vector drawing tool, but since they have so little between them, and 
no one seem to be maintaining flow.
  
  So I'm okay with it

REPOSITORY
  R8 Calligra

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

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


D24852: Remove list style from headings

2019-11-08 Thread Camilla Boemann
boemann added a comment.


  Not strange for a normal list - but yes for headings it sounds wrong - and I 
think this is where you need to make the changes.
  
  So if in load odf you are loading a heading and it doesn't specify numbering 
set it formatspecification to empty.
  
  But please make sure that "it doesn't specify numbering" is  checked in 
parent styles etc. Also if the code is shared with presenter then presenter 
probably should react differently.  the fix is probably not simple at all, but 
keep digging and check the odf standard specification

REPOSITORY
  R8 Calligra

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

To: akomakhin, pvuorela, #calligra:_3.0, boemann
Cc: anthonyfieroni, boemann, Calligra-Devel-list, davidllewellynjones, 
dcaliste, cochise, vandenoever


D24852: Remove list style from headings

2019-11-08 Thread Camilla Boemann
boemann added a comment.


  This looks scarily generic
  
  What happens when the user via gui adds a numbered lists, and what is the 
impact  in the other applications
  
  You are definitely on to something with formatSpecification, but maybe not 
setting is for all but only when loading headers without numbers.

REPOSITORY
  R8 Calligra

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

To: akomakhin, pvuorela, #calligra:_3.0, boemann
Cc: anthonyfieroni, boemann, Calligra-Devel-list, davidllewellynjones, 
dcaliste, cochise, vandenoever


D24852: Remove list style from headings

2019-10-25 Thread Camilla Boemann
boemann added a comment.


  All I'm saying is removing it completely is probably just as wrong as leaving 
it in. Maybe you could come up with some if case

REPOSITORY
  R8 Calligra

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

To: akomakhin, pvuorela, #calligra:_3.0, boemann
Cc: boemann, Calligra-Devel-list, dcaliste, cochise, vandenoever


D24852: Remove list style from headings

2019-10-22 Thread Camilla Boemann
boemann added a reviewer: boemann.

REPOSITORY
  R8 Calligra

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

To: akomakhin, pvuorela, #calligra:_3.0, boemann
Cc: boemann, Calligra-Devel-list, dcaliste, cochise, vandenoever


D24852: Remove list style from headings

2019-10-22 Thread Camilla Boemann
boemann added a comment.


  I think this will break those headings that actually should have numbering, 
so i think further investigation is needed with such cases

REPOSITORY
  R8 Calligra

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

To: akomakhin, pvuorela, #calligra:_3.0
Cc: boemann, Calligra-Devel-list, dcaliste, cochise, vandenoever


D24830: Add support for strikeout text in RTF documents

2019-10-21 Thread Camilla Boemann
boemann added a comment.


  As far as I'm concerned you may push to rtf importer at your own discretion

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

To: akomakhin, pvuorela, #calligra:_3.0
Cc: boemann, Calligra-Devel-list, dcaliste, cochise, vandenoever


D7946: CSV characters should not be translated

2019-09-14 Thread Camilla Boemann
boemann accepted this revision.
boemann added a comment.


  Looks simple enough to me too - someone please push

REPOSITORY
  R8 Calligra

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

To: guoyunhe, #calligra:_3.0, danders, mecir, boemann
Cc: boemann, Calligra-Devel-list, anthonyfieroni, dcaliste, cochise, vandenoever


D22545: Add missing include QDate

2019-07-19 Thread Camilla Boemann
boemann accepted this revision.
boemann added a comment.
This revision is now accepted and ready to land.


  btw For such small fixes we don't usually require review

REPOSITORY
  R8 Calligra

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

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


D19216: Karbon: Enable multi page capability

2019-02-28 Thread Camilla Boemann
boemann added a comment.


  In D19216#421654 , @rjvbb wrote:
  
  > >   No, the canvas is part of the document and must never be themed. The 
canvas background is as much part of your drawing as any line you put on it.
  >
  > This hasn't been sitting right with me and I finally realised why.
  >
  > That statement is true when you work with a real canvas and 
draw/paint/whatever directly onto that. If you take a grid paper the grid will 
become part of your art, but does Karbon print the grid which you can have it 
show (except possibly via an option)?
  >
  > In drawing applications, the canvas is NOT part of your art, but simulates 
the canvas you'll be printing on. It's a backdrop layer that sits behind/below 
the lowest layer you can draw on. If you plan to print on a coloured piece of 
paper, or one with a canvassy texture, you'll probably want to adapt your 
virtual canvas so you can incorporate the physical canvas properties into your 
design. But you don't want that virtual canvas to print as that would be a 
waste of toner at best...
  
  
  That is actual a valid point, although in say Krita with transparent pixels a 
checkerboard is shown.
  That said it might make more sense for this "testing background" to be part 
of the document and not a general setting - if the use case is as you say then 
the testing background would also be different for different projects
  
  > That's not to say that the virtual canvas should not be exportable at all: 
you'd want to be able to include it when generating a PDF (SVG, JPG, etc) 
format version for use in on-screen only presentations. Of course you could 
just add a backdrop layer in that case.
  > 
  > I'm not aware that Karbon has the equivalent of a slide/page design feature 
where you can define how each page will look. That could look be used to be 
achieve what I describe here but in Karbon that layer should probably not be 
printed by default (just like it isn't in presentation apps, IIRC).

REPOSITORY
  R8 Calligra

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

To: danders, anthonyfieroni
Cc: boemann, rjvbb, Calligra-Devel-list, dcaliste, cochise, vandenoever


D15428: [textlayout] Don't enter infinite loop when table is misfit

2019-02-25 Thread Camilla Boemann
boemann added a comment.


  no

REPOSITORY
  R8 Calligra

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

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


D19216: Karbon: Enable multi page capability

2019-02-25 Thread Camilla Boemann
boemann added a comment.


  totally agree about not theme'ing canvas
  
  Also a general agreement to do the page app thing as long as it's also 
supported in svg
  
  odg is hardly that much of a reason - it even seems like odf is moving away 
from odg as much as possible

REPOSITORY
  R8 Calligra

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

To: danders, anthonyfieroni
Cc: boemann, rjvbb, Calligra-Devel-list, dcaliste, cochise, vandenoever


D18989: Remove minor duplicate code and fix related bug

2019-02-13 Thread Camilla Boemann
boemann accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R8 Calligra

BRANCH
  dev

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

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


D18843: Activate stencils docker in all apps

2019-02-13 Thread Camilla Boemann
boemann accepted this revision.
boemann added a comment.
This revision is now accepted and ready to land.


  I definitely don't want this docker default on, but if as you say it's 
default off then i guess your change is okay - i'll take your word for it

REPOSITORY
  R8 Calligra

BRANCH
  activate_stencils_danders

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

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


D18466: Fixed calligra crashing when opening remote document

2019-02-12 Thread Camilla Boemann
boemann added a comment.


  Dan can you please reply - I'm fine with the account but I can't reply to Ben 
as I am not able to send email

REPOSITORY
  R8 Calligra

BRANCH
  print-remote-files (branched from master)

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

To: niccolove, danders
Cc: anthonyfieroni, boemann, Calligra-Devel-list, dcaliste, cochise, vandenoever


D18963: Improve KoModeBox display in horizontal Mode

2019-02-12 Thread Camilla Boemann
boemann accepted this revision.
boemann added a comment.
This revision is now accepted and ready to land.


  I like it

REPOSITORY
  R8 Calligra

BRANCH
  calligra/3.1

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

To: ognarb, #calligra:_3.0, #vdg, boemann
Cc: boemann, anthonyfieroni, abetts, ngraham, Calligra-Devel-list, dcaliste, 
cochise, vandenoever


D18466: Fixed calligra crashing when opening remote document

2019-01-30 Thread Camilla Boemann
boemann added a comment.


  regarding the lambda connection - nice to see that you use the version with  
a "still alive" argument - but I fear this requires a qt version  higher than 
what we currently support - could you please check

REPOSITORY
  R8 Calligra

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

To: niccolove, danders
Cc: anthonyfieroni, boemann, Calligra-Devel-list, dcaliste, cochise, vandenoever


D18466: Fixed calligra crashing when opening remote document

2019-01-23 Thread Camilla Boemann
boemann added a comment.


  Please check with loading a normal document,. The same concerns now applies 
to slotLoadCompleted - especially since you have now removed functionality from 
it.
  
  Also please check in all of our applications as some might reimplement 
virtual methods

REPOSITORY
  R8 Calligra

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

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


D18466: Fixed calligra crashing when opening remote document

2019-01-23 Thread Camilla Boemann
boemann added a reviewer: danders.

REPOSITORY
  R8 Calligra

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

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


D18466: Fixed calligra crashing when opening remote document

2019-01-23 Thread Camilla Boemann
boemann added a comment.


  Yes that description helped a lot, and you are doing great. Keep up the good 
work :)
  
  One concern though - how often and when is openDoumentInternal called. I'm a 
bit afraid that we just add some functionality to a place that might be used 
for something else

REPOSITORY
  R8 Calligra

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

To: niccolove
Cc: boemann, Calligra-Devel-list, dcaliste, cochise, vandenoever


D18466: Fixed calligra crashing when opening remote document

2019-01-23 Thread Camilla Boemann
boemann added a comment.


  Could you please describe what you have done and why

REPOSITORY
  R8 Calligra

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

To: niccolove
Cc: boemann, Calligra-Devel-list, dcaliste, cochise, vandenoever


D18448: Replaced "distraction free" with "fullscreen" - BUG:378527

2019-01-22 Thread Camilla Boemann
boemann accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R8 Calligra

BRANCH
  replace-disturbfree-with-fullscreen (branched from master)

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

To: niccolove, boemann
Cc: Calligra-Devel-list, dcaliste, cochise, vandenoever


D18095: Add new table layout unit tests

2019-01-15 Thread Camilla Boemann
boemann added a comment.


  absolutely

REPOSITORY
  R8 Calligra

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

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


D18095: Add new table layout unit tests

2019-01-08 Thread Camilla Boemann
boemann added a comment.


  Looks like a good first start to me - do they pass currently? - if so then i 
think they should be pushed
  
  I'll think about further tests

REPOSITORY
  R8 Calligra

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

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


D15428: [textlayout] Don't enter infinite loop when table is misfit

2018-12-18 Thread Camilla Boemann
boemann added a comment.


  good investigative work, but I fear those tests are way too simple to dare 
apply the patch.
  
  The table code handles a lot more cases than a simple 2x1 table merged will 
uncover. I'm a bit surprised of the problems you describe in master - I don't 
recall any such problems.
  
  I think it is time that we create a lot of unittests. Unittesting table 
layout is long overdue anyway

REPOSITORY
  R8 Calligra

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

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


D15428: [textlayout] Don't enter infinite loop when table is misfit

2018-12-17 Thread Camilla Boemann
boemann added a comment.


  And has anyone been able to produce a smaller 1  page example of the document 
- we are stumbling blindly here.
  Do we have an odf snippet of the table that gives the problem?

REPOSITORY
  R8 Calligra

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

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


D15428: [textlayout] Don't enter infinite loop when table is misfit

2018-12-17 Thread Camilla Boemann
boemann added a comment.


  Still not the description i was looking for. I want to know what the extreme 
case is and what the resulting document should look like when we give up:
  
  A table without header rows and that doesn't fit  will be layouted and shown 
in pieces
  
  What I want to know is: What should we do?.
  
  1. Should we not show the header rows- it will leave the user without context 
but at least the user will get to see normal rows
  2. should we layout one line past the headerrows even though that will never 
be visible on the printed paper (and then nothing interesting will ever be 
visible) - Should we then show the table at all instead of 100s of pages with 
just headerrows until we have disposed of all the contents one line at a time.
  
  You see - to me - it's not at all clear what it is we are trying to accomplish

REPOSITORY
  R8 Calligra

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

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


D15428: [textlayout] Don't enter infinite loop when table is misfit

2018-12-17 Thread Camilla Boemann
boemann added a comment.


  No you misunderstand. I wasn't talking about you diff - I want to know what 
it is we are trying to accomplish. in spoken words

REPOSITORY
  R8 Calligra

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

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


D15428: [textlayout] Don't enter infinite loop when table is misfit

2018-12-17 Thread Camilla Boemann
boemann added a comment.


  Dan I like your diff better - I don't think it's completely there but it's a 
better starting point
  
  On a more conceptual level, what should happen if the design of table is such 
that headers can't fit on a virgin page? What should we do.? One one hand it 
should be there but on the other hand we will never get to show the real part 
of the table ever.
  What is the solution we should aim for?

REPOSITORY
  R8 Calligra

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

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


D16679: Words: Fix interop problem with LO/OO

2018-11-05 Thread Camilla Boemann
boemann accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R8 Calligra

BRANCH
  words_pagestyle_danders

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

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


D16367: EnhancedPathShape: Shape is moved/resized on save/load

2018-10-22 Thread Camilla Boemann
boemann added a comment.


  As I recall it was one of the files in the huge dataset - there should be a 
bug on it

REPOSITORY
  R8 Calligra

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

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


D16367: EnhancedPathShape: Shape is moved/resized on save/load

2018-10-22 Thread Camilla Boemann
boemann added a comment.


  Yes as i recall that code was made to handle masks being exported correctly 
for  OpenOffice or LO - I'd strongly prefer it not being thrown away like that

REPOSITORY
  R8 Calligra

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

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


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

2018-09-26 Thread Camilla Boemann
boemann added a comment.


  Ahh well in that case I don't mind and the words code looks clean enough - 
I'll let someone else review the components

REPOSITORY
  R8 Calligra

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

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


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

2018-09-26 Thread Camilla Boemann
boemann added a comment.


  'm sorry but the background should not be settable - it's a document property 
at best and in fact paper is mostly white,  so shouldn't even be settable

REPOSITORY
  R8 Calligra

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

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


D15728: Try to avoid segfaults on shape factory not found

2018-09-24 Thread Camilla Boemann
boemann accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R8 Calligra

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

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


D15549: Words: Save anchor info also for page-anchored shapes

2018-09-17 Thread Camilla Boemann
boemann accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R8 Calligra

BRANCH
  danders_words_anchor

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

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


D15549: Words: Save anchor info also for page-anchored shapes

2018-09-16 Thread Camilla Boemann
boemann added a comment.


  Bah I can't remember this, but page anchored shapes don't have anchors as 
such, so I'm wondering what exactly is this writing to file?

REPOSITORY
  R8 Calligra

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

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


D15412: [filters] Extend table lifetime

2018-09-13 Thread Camilla Boemann
boemann added a comment.


  No idea either - jaroslaw was the original author so maybe he can take a look

REPOSITORY
  R8 Calligra

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

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


D15428: [textlayout] Don't enter infinite loop when table is misfit

2018-09-12 Thread Camilla Boemann
boemann added a comment.


  I am more thinking of this place:
  
  
https://phabricator.kde.org/source/calligra/browse/master/libs/textlayout/KoTextLayoutTableArea.cpp$436
  
  this shouldn't be set if we are doing a headerrow, so please try this:
  
  if (cursor->row >= d->headerRows)
  
setVirginPage(false);
  
  It may still not be enough to fix the problem but it's step in the right 
direction i think 
  There is still the possibility that the user has completely written more than 
can be fitted - I wonder what we should do in that case then

REPOSITORY
  R8 Calligra

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

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


D15428: [textlayout] Don't enter infinite loop when table is misfit

2018-09-12 Thread Camilla Boemann
boemann added a comment.


  The idea is that if we are at the beginning of a new page we don't get in 
here (virginpage is true)
  so we only reset if we are somewhere down on a page meaning we wil have more 
space to try on next time around
  But we should reset if the only thing we fitted was the table header as a 
table headerrow should never be the only thing on a page
  
  One reason why this might fail is if virginpage becomes false when we add the 
table headerrow (if we can fix this and that doesn't have other ill effect then 
I would prefer such a solution).
  So find out where we set virginpage to false, and make sure it doesn't go 
from true to false when adding the header row
  
  I hope this makes sense

REPOSITORY
  R8 Calligra

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

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


D15428: [textlayout] Don't enter infinite loop when table is misfit

2018-09-11 Thread Camilla Boemann
boemann added inline comments.

INLINE COMMENTS

> KoTextLayoutNoteArea.cpp:143
> +
> +if (blockLayoutLine.isValid()) {
> +d->labelYOffset += blockLayoutLine.ascent();

I'm fine with this change

> KoTextLayoutTableArea.cpp:464
> +//if we couldn't fit the header rows
> +//try again don't reset cursor->row or we enter infinite loop
> +//cursor->row = 0;

nah this is too aggressive.
There are definitely cases where setting to 0 is the correct thing to do.
There might be some times we enter an infinite loop yes, but we need to catch 
this is some other way

REPOSITORY
  R8 Calligra

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

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


D15403: {Style] Default sheets to white background

2018-09-10 Thread Camilla Boemann
boemann added a comment.


  No Idea about the code, but in general I have no problem with sheets 
respecting the palette

REPOSITORY
  R8 Calligra

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

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


D14901: Fix blocklayout unittest after percentage lineheight was fixed in D9537

2018-08-31 Thread Camilla Boemann
boemann accepted this revision.
boemann added a comment.
This revision is now accepted and ready to land.


  I like what you have done - you seem to understand the concepts, so please 
commit when you feel  like it's working

INLINE COMMENTS

> TestBlockLayout.cpp:333
>  //qDebug() << blockLayout->lineAt(0).y();
> -QVERIFY(qAbs(blockLayout->lineAt(0).y() - (0.8*12 + 28.0-12.0 + 100.0)) 
> < ROUNDING);
> +QEXPECT_FAIL("", "FIXME: Should not this calculate with lineheight and 
> not fontsize?", Continue);
> +QVERIFY2(qAbs(blockLayout->lineAt(0).y() - line2_y) < ROUNDING, 
> QString("Actual: %1 Expected: 
> %2").arg(blockLayout->lineAt(0).y()).arg(line2_y).toLatin1());

yes I think so

REPOSITORY
  R8 Calligra

BRANCH
  blocklayout_unittest_danders

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

To: danders, boemann, anthonyfieroni
Cc: Calligra-Devel-list, cochise, vandenoever


D15111: [KoUnit] Let's show pixel units

2018-08-29 Thread Camilla Boemann
boemann added a comment.


  And none of that contradicts me saying it's not a general feature we want, 
but at most for Karbon, and that since we don't store pixel values but rather 
convert to points the user will not get pixel precise placement anyway

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, boemann, danders, #calligra:_3.0
Cc: staniek, Calligra-Devel-list, cochise, vandenoever


D15103: Replace deprecated use of QWeakPointer in favor of QPointer

2018-08-29 Thread Camilla Boemann
boemann added a comment.


  I have no fundamentally against it, but I cannot test it right - so if it 
works 'm all for it

REPOSITORY
  R8 Calligra

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

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


D15111: [KoUnit] Let's show pixel units

2018-08-29 Thread Camilla Boemann
boemann added a comment.


  discard as a general solution - it doesn't make close to any sense for other 
than karbon when used as a tool to generate pixmaps in the end, and even then 
as I said it's a bad idea for various reasons

REPOSITORY
  R8 Calligra

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

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


D15111: [KoUnit] Let's show pixel units

2018-08-28 Thread Camilla Boemann
boemann added a comment.


  The problem here is if they think they can place a line on a specific pixel 
position - we don't store coords as pixels - so  it will not end being rendered 
to a specific pixel anyway - we will just end up with users not getting what 
they think they get, even in such a case as you describe

REPOSITORY
  R8 Calligra

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

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


D15111: [KoUnit] Let's show pixel units

2018-08-28 Thread Camilla Boemann
boemann added a comment.


  Yes, that is exactly how they could use it but, I think we are doing a 
disservice by offering such an option- there is no way an author can know the 
destination resolution and it will only apply to one destination.
  
  Besides why would they even need to know - we are not pixel base to begin 
with, we are all vectors
  
  I'm convinced that most users are just not understanding how wrong pixel unit 
is - we should not contribute by letting pixel units be available

REPOSITORY
  R8 Calligra

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

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


D15111: [KoUnit] Let's show pixel units

2018-08-28 Thread Camilla Boemann
boemann added a comment.


  What is the purpose of showing pixel units in general - pixels is not really 
a unit except in very specific cases - I'd saythis is very very wrong
  
  What is the size of pixel in your mind anyway?

REPOSITORY
  R8 Calligra

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

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


D9537: [kotextlayoutarea] Make percentage line height relative to the default height

2018-07-30 Thread Camilla Boemann
boemann added a comment.


  given that we no multiply with1.16 the values should be: 12*1.16, 24*1.16,  no
  Don't know what the last is supposed to be but it  should probably have the 
same treatment

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, danders, mecir, boemann
Cc: Calligra-Devel-list, cochise, vandenoever


D9537: [kotextlayoutarea] Make percentage line height relative to the default height

2018-07-22 Thread Camilla Boemann
boemann accepted this revision.
boemann added a comment.


  Thanks

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, danders, mecir, boemann
Cc: Calligra-Devel-list, cochise, vandenoever


D9537: [kotextlayoutarea] Make percentage line height relative to the default height

2018-07-22 Thread Camilla Boemann
boemann added a comment.


  except that its 1, 1½, 2 and not 1,2,3 then it looks good

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, danders, mecir, boemann
Cc: Calligra-Devel-list, cochise, vandenoever


D9537: [kotextlayoutarea] Make percentage line height relative to the default height

2018-07-22 Thread Camilla Boemann
boemann added a comment.


  yes and line 233-235 in the same file - fix that and we are ready to push

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, danders, mecir, boemann
Cc: Calligra-Devel-list, cochise, vandenoever


D9537: [kotextlayoutarea] Make percentage line height relative to the default height

2018-07-21 Thread Camilla Boemann
boemann added a comment.


  in plugins/textshape/dialogs there is a file that handles line height (can't 
remember which exactly)
  
  when converting between the 1x, 2x etc and a percentage it right now aplies 
the 1.2
  
  but this is wrong: it should just convert 1x as 100%, 2x as 200%
  
  The 1.2 (or actually 1..16) is just a  behind the scenes detail handled in 
layout

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, danders, mecir, boemann
Cc: Calligra-Devel-list, cochise, vandenoever


D9537: [kotextlayoutarea] Make percentage line height relative to the default height

2018-06-03 Thread Camilla Boemann
boemann added a comment.


  no just:
  
  if (percent != 0)
  
height *= percent/100
  
  height *= 1.16;

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, danders, mecir, boemann
Cc: Calligra-Devel-list, cochise, vandenoever


D9537: [kotextlayoutarea] Make percentage line height relative to the default height

2018-06-02 Thread Camilla Boemann
boemann added a comment.


  So now we are just missing the texttool ui changes

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, danders, mecir, boemann
Cc: Calligra-Devel-list, cochise, vandenoever


D9537: [kotextlayoutarea] Make percentage line height relative to the default height

2018-05-30 Thread Camilla Boemann
boemann added a comment.


  Okay I basically believe you are right, but before I accept I ask you to make 
the corresponding changes in
  textshape/dialogs/ParagraphIndentSpacing.cpp
  
  Where the 120% should be 100% etc
  
  Also having tested with Libreoffice I think the correct scale is 1.16
  
  And finally the code you already wrote can be simplyfied by by not having an 
else but always multiplying
  
  Also 5 lines below a similar factor for dropcaps should probably also be 1.16
  
  Sorry it took me this long to look into it

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, danders, mecir, boemann
Cc: Calligra-Devel-list, cochise, vandenoever


D9537: [kotextlayoutarea] Make percentage line height relative to the default height

2018-05-30 Thread Camilla Boemann
boemann added a comment.


  I have my linux partiotion working again, so I'l take a look this weekend - 
is there a bug number and a test document somewhere ?

REPOSITORY
  R8 Calligra

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

To: anthonyfieroni, danders, mecir, boemann
Cc: Calligra-Devel-list, cochise, vandenoever


please turn off comments for calligra site

2017-07-24 Thread Camilla Boemann
There are way too many spam messages these 

 

Days so could someone with admin rights please turn them off or install a
captcha or something

 

Also it would be ice if more of us had admin rights

 

Please help out asap

 

 



D6844: clazy fixes for kostore

2017-07-22 Thread Camilla Boemann
boemann accepted this revision.
boemann added a comment.
This revision is now accepted and ready to land.


  No need to review these very simple changes - just make sure you test before 
pushing

REPOSITORY
  R8 Calligra

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

To: vandenoever, #calligra:_3.0, Calligra-Devel-list, boemann
Cc: boemann, vandenoever


Re: Review Request 130196: Add a seed parameter to make the qHash used

2017-07-22 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130196/#review103464
---


Ship it!




Ship It!

- Camilla Boemann


On July 22, 2017, 7:50 p.m., Jos van den Oever wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130196/
> ---
> 
> (Updated July 22, 2017, 7:50 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Without the seed parameter, the default qHash for QPair is used.
> The seed argument in qHash was introduced in Qt 5.0. The qHash for
> KoXmlStringPair did not have it and hence it was an unused function.
> 
> 
> Diffs
> -
> 
>   libs/store/KoXmlReader.cpp 4c7f434 
> 
> Diff: https://git.reviewboard.kde.org/r/130196/diff/
> 
> 
> Testing
> ---
> 
> All unit tests in kostore still pass.
> 
> 
> Thanks,
> 
> Jos van den Oever
> 
>



RE: Release 3.0.1

2017-03-11 Thread Camilla Boemann
Nothing new from my end, so please go ahead

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of
Dag
Sent: 10. marts 2017 13:03
To: calligra-devel@kde.org
Subject: Release 3.0.1

Hi, should we make a bug fix release soon?

A few bugs has been fixed, and there is 3 months since 3.0.0 ;)

Anybody has something that *needs* to be fixed?

Cheers,
Dag



RE: isn't it time for...

2017-01-15 Thread Camilla Boemann
Done

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of
Boudewijn Rempt
Sent: 14. januar 2017 20:29
To: calligra-devel@kde.org
Subject: isn't it time for...

A release announcement?

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org



Re: Review Request 129782: [calligra] Buildsystem improvements

2017-01-06 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129782/#review101845
---


Ship it!




Ship It!

- Camilla Boemann


On Jan. 6, 2017, 10:58 p.m., Andreas Sturmlechner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129782/
> ---
> 
> (Updated Jan. 6, 2017, 10:58 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> 3 commits:
> 
> - Make Activities and KF5Html really optional.
>   Before, trying to use CMAKE_DISABLE_FIND_PACKAGE_KF5{Activities,KHtml} 
> errored out with:
>   "if given arguments: "VERSION_LESS" "5.16.0" Unknown arguments specified"
> 
> - Fix dependencies, sort and clean trailing whitespaces:
>   Add missing KF5JobWidgets
>   Drop unused KF5TextEditor
> 
> - Push KF5Threadweaver dep to the only place where it is used
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 3779c9abeff3642ac867c497a2eef637276f8835 
>   libs/widgets/tests/CMakeLists.txt 39346304bb2c95ce12fea528998a512ab42d19cb 
> 
> Diff: https://git.reviewboard.kde.org/r/129782/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sturmlechner
> 
>



RE: 3.0.0.1 tarball + signature

2017-01-05 Thread Camilla Boemann
Sure but I did say in my draft that we are porting and that it sets a bright 
new future – but really for the average user it doesn’t matter much what kind 
of tools we use – it’s what it means for the user that is important

 

From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of 
Jaroslaw Staniek
Sent: 5. januar 2017 11:45
To: Calligra Suite developers and users mailing list 
Subject: Re: 3.0.0.1 tarball + signature

 

 

 

On 5 January 2017 at 11:32, Boudewijn Rempt  > wrote:

On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:

> On 5 January 2017 at 11:05, Boudewijn Rempt   > wrote:
>
> > On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
> >
> > > IMHO ​If it's not​ marked as a big thing, the media and users will
> > > definitely mark this as not important and move over. Inkscape just made a
> > > release that highlights a port to GTK+3 as an important news.
> >
> > Um... The version inkscape just released isn't the gtk3 port, it's still
> > gtk2 based.
> >
> > ​I referred to
> https://inkscape.org/en/news/2017/01/04/inkscape-version-092-released/
> and it ​
>
> ​marks C++ upgrade and Gtk3 port as important.
> ​
>

No: it says "(Future infrastructure changes include switching from bzr to git, 
shifting from Gtk2 to Gtk3, and moving to the C++11 standard.)" I.e., that's 
what they're going to do.

 

Sorry, just noticed this, hard grammar to me; regardless, they found it 
important to notify users what they do apart of adding features and more 
importantly why :)
​

 



-- 

regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek



RE: 3.0.0.1 tarball + signature

2017-01-03 Thread Camilla Boemann
Right, but that is just for a mail right ?

I mean our website announcement should be a bit more for end users

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of
Dag
Sent: 3. januar 2017 13:46
To: Calligra Suite developers and users mailing list
<calligra-devel@kde.org>
Subject: RE: 3.0.0.1 tarball + signature

Camilla Boemann skrev den 2017-01-03 12:59:
> I have prepared a release announcement, but it doesn't say much so 
> maybe someone has suggestions as to what we should highlight?

I was thinking something like this for the packagers:

A new version of Calligra has been released and files can be found here:
http://download.kde.org/stable/calligra/3.0.0.1/calligra-3.0.0.1.tar.xz
http://download.kde.org/stable/calligra/3.0.0.1/calligra-3.0.0.1.tar.xz.sig

Public key:
https://share.kde.org/index.php/s/fJ99V5mZvuyD0z8


Dependencies:
-
Note that atm Plan depends on KProperty and KReport version 3.0.0 exactly.
Afaik this is the only version released so far.

Building:
-
Note that the tarball contains modules that should not be included in the
release.
This release shall include the follow main apps: Words, Sheets, Karbon and
Plan.
The following main apps shall not be included: Stage, Flow and Braindump.

Specify the cmake flag:

-DRELEASE_BUILD=true

to only build the modules that shall be released.

See README.PACKAGERS for details.

Unit tests
--
Some unit tests fails if not run in the C locale, use LC_ALL=C make test to
avoid these failures.

Some unit tests fails but can be disregarded:
sheets-DatetimeFunctions
sheets-ValueConverter
sheets-ValueParser
libs-koodf-TestNumberStyle
libs-pigment-TestColorConversionSystem

Bug fixes:
--
This is mainly a port to KF5/Qt5, but some serious bugs present in
2.9.11 has been fixed:

Plan:
Fixed crash on startup, crash on close, crash when selecting New.

Words
Fixed crash when adding connected text frame.

ChartShape:
Fixed crash when adding a second chart.





RE: 3.0.0.1 tarball + signature

2017-01-03 Thread Camilla Boemann
I have prepared a release announcement, but it doesn't say much so maybe
someone has suggestions as to what we should highlight?

https://www.calligra.org/?p=4837=true

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of
Boudewijn Rempt
Sent: 3. januar 2017 11:58
To: Calligra Suite developers and users mailing list

Subject: Re: 3.0.0.1 tarball + signature

On Tue, 3 Jan 2017, Boudewijn Rempt wrote:

> On Tue, 3 Jan 2017, Dag wrote:
> 
> > Looks fine, it's a go from me!
> 
> Okay -- as soon as someone has done a release announcment, I'll upload 
> and we can publish.

Oh, and I've put the public key here:

https://share.kde.org/index.php/s/fJ99V5mZvuyD0z8

(If I did everything correctly)

> 
> > 
> > Dag skrev den 2017-01-02 13:49:
> > > Boudewijn Rempt skrev den 2017-01-02 13:12:
> > > > I've updated the tarball and the sig -- the tarball is now 58M
> > > Yes, looks better, I'm running a clean build now to test.
> > > 
> > > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > > 
> > > > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > > > 
> > > > > > Weird... I just let the script do its work, and then sign 
> > > > > > manually. So
> > > > > it
> > > > > > should compress the tarball. Even weirder, when I tried 
> > > > > > today, it
> > > > > suddenly
> > > > > > started asking for my key's passphrase for checking out the
> > > > > translations
> > > > > > a zillion times.
> > > > > 
> > > > > Hm, looks like that was a glitch...
> > > > > 
> > > > > >
> > > > > > On Mon, 2 Jan 2017, Dag wrote:
> > > > > >
> > > > > > > Hi, Boudewijn
> > > > > > > Happy new year.
> > > > > > >
> > > > > > > The tarball seems ok, except it is not compressed.
> > > > > > > The create_tarball script also uses the -a (or --armor) 
> > > > > > > option to
> > > > > sign.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Dag
> > > > > > >
> > > > > > > Boudewijn Rempt skrev den 2016-12-28 15:05:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I've finally figured out how to fix gpg-agent, so next 
> > > > > > > > to
> > > > > > > >
> > > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz
> > > > > > > >
> > > > > > > > there's now also
> > > > > > > >
> > > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz.sig
> > > > > > > >
> > > > > > > > which you can use to check whether I've done everything
> > > > > correctly...
> > > > > > > >
> > > > > > > > This should be the corresponding public key:
> > > > > > > >
> > > > > > > > http://valdyas.org/~boud/0x58b9596c722ea3bd.asc
> > > > > > > >
> > > > > > > > (anyone know of a better place to put that? My webserver 
> > > > > > > > isn't configured to use https yet...)
> > > > > > >
> > > > > >
> > > > > >
> > > > > 
> > > > > 
> > 
> 
> 

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org



Re: Review Request 129682: calligra: Update Czech Republic to Czechia

2016-12-21 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129682/#review101530
---


Ship it!




Ship It!

- Camilla Boemann


On Dec. 20, 2016, 9:09 p.m., Jiri Bohac wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129682/
> ---
> 
> (Updated Dec. 20, 2016, 9:09 p.m.)
> 
> 
> Review request for Calligra and Albert Astals Cid.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This year the country has oficially adopted the short name Czechia.
> The short name has been entered to the UNTERM and UNGEGN databases in July 
> 2016.
> Czechia is used in iso_3166 since September 2016.
> 
> This is a followup to
> https://git.reviewboard.kde.org/r/129644/
> As suggested by Albert Astals Cid, fixing the name in i10n is not enough: 
> country names are hardcoded in many places and they need to be fixed 
> separately.
> 
> 
> Diffs
> -
> 
>   karbon/stencils/Flags/czech_republic.desktop 0815af9 
>   karbon/stencils/Flags/czech_republic.odg 
> 8c01b1d306e83b97b1fd4925e81c23277415aebf 
>   karbon/stencils/Flags/czech_republic.png 
> c4bee8e4b4ad113b324544a48ae52f4c3a4fecd1 
>   karbon/stencils/Flags/czechia.desktop PRE-CREATION 
>   karbon/stencils/Flags/czechia.odg PRE-CREATION 
>   karbon/stencils/Flags/czechia.png PRE-CREATION 
>   sheets/Currency.cpp 48cf9ac 
> 
> Diff: https://git.reviewboard.kde.org/r/129682/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jiri Bohac
> 
>



Re: Review Request 129421: [karbon] Returning of Karbon as maintained product

2016-11-26 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129421/#review101127
---



Also Anthony - for the really simple commits and stuff in karbon you can just 
commit without review request - we will review when we see the commit mails - 
just don't break build or push big stuff without some kind of warning etc

- Camilla Boemann


On Nov. 26, 2016, 6:12 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129421/
> ---
> 
> (Updated Nov. 26, 2016, 6:12 a.m.)
> 
> 
> Review request for Calligra, Camilla Boemann and Friedrich W. H. Kossebau.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> As https://community.kde.org/Calligra/Maintainers Karbon has a maintainer, so 
> i can be Co-Maintainer, i'm missing experience with graphics nor vector 
> graphics software but i will try to help and fixing bugs.
> 
> 
> Diffs
> -
> 
>   CalligraProducts.cmake 965e9d8 
> 
> Diff: https://git.reviewboard.kde.org/r/129421/diff/
> 
> 
> Testing
> ---
> 
> Builds.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129514: [connectionTool] Check dynamic_cast return type

2016-11-25 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129514/#review101109
---


Ship it!




Ship It!

- Camilla Boemann


On Nov. 21, 2016, 5:42 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129514/
> ---
> 
> (Updated Nov. 21, 2016, 5:42 a.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Bugs: 326258
> http://bugs.kde.org/show_bug.cgi?id=326258
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> I can't reproduce these days, but it's safe to check. Correct is based on 
> backtrace in bug report.
> 
> 
> Diffs
> -
> 
>   plugins/defaultTools/connectionTool/ConnectionTool.cpp 9e3dec6 
> 
> Diff: https://git.reviewboard.kde.org/r/129514/diff/
> 
> 
> Testing
> ---
> 
> PS: I manage to work on 2 wishlist, Px (pixels) if can be enabled from 
> settings (i still don't know why it's disabled) and export arrow line in SVG. 
> Other bus looks really outdated.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129532: [shortcuts] Undo / Redo shortkeys

2016-11-23 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129532/#review101087
---


Ship it!




Ship It!

- Camilla Boemann


On Nov. 23, 2016, 5:36 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129532/
> ---
> 
> (Updated Nov. 23, 2016, 5:36 a.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> + fullscreen action provide warning on runtime "Use 
> actionCollection->setDefaultShortcut instead of QAction->setShortcut
> 
> 
> Diffs
> -
> 
>   libs/main/KoMainWindow.cpp 828d789 
>   libs/main/KoView.cpp f3b6fd9 
> 
> Diff: https://git.reviewboard.kde.org/r/129532/diff/
> 
> 
> Testing
> ---
> 
> Build and run with Karbon
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129532: [shortcuts] Undo / Redo shortkeys

2016-11-22 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129532/#review101060
---


Ship it!




but i just meant to use QKeySequence::Undo and redo

- Camilla Boemann


On Nov. 22, 2016, 8:30 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129532/
> ---
> 
> (Updated Nov. 22, 2016, 8:30 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> + fullscreen action provide warning on runtime "Use 
> actionCollection->setDefaultShortcut instead of QAction->setShortcut
> 
> 
> Diffs
> -
> 
>   libs/main/KoMainWindow.cpp 828d789 
>   libs/main/KoView.cpp f3b6fd9 
> 
> Diff: https://git.reviewboard.kde.org/r/129532/diff/
> 
> 
> Testing
> ---
> 
> Build and run with Karbon
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129532: [shortcuts] Undo / Redo shortkeys

2016-11-22 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129532/#review101058
---




libs/main/KoView.cpp (line 342)
<https://git.reviewboard.kde.org/r/129532/#comment67757>

hmm we shouldn't hardcode these key combinations


- Camilla Boemann


On Nov. 22, 2016, 7:27 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129532/
> ---
> 
> (Updated Nov. 22, 2016, 7:27 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> + fullscreen action provide warning on runtime "Use 
> actionCollection->setDefaultShortcut instead of QAction->setShortcut
> 
> 
> Diffs
> -
> 
>   libs/main/KoMainWindow.cpp 828d789 
>   libs/main/KoView.cpp f3b6fd9 
> 
> Diff: https://git.reviewboard.kde.org/r/129532/diff/
> 
> 
> Testing
> ---
> 
> Build and run with Karbon
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129421: [karbon] Returning of Karbon as maintained product

2016-11-20 Thread Camilla Boemann


> On Nov. 17, 2016, 10:09 p.m., Camilla Boemann wrote:
> > It's great that you want to co maintain - i think you could even apply for 
> > maintaining without the "co-", but i also think it's a bit premature to 
> > remove that message. Maintain (be ambassador, fix bugs etc) for a month or 
> > so and if you are still warm about the idea we can remove the message.I 
> > mean the spot is yours if you want but make yourself a maintainer by deed 
> > before we make you one by name. Deal?
> > 
> > And just to emphazise it would be really great to see you work on karbon - 
> > it deserves to come to full glory!
> 
> Anthony Fieroni wrote:
> So you want to return warn message on non-Release builds?
> 
> Camilla Boemann wrote:
> I'm sorry I don't understand what you mean? Also karbon doesn't have a 
> maintainter. That webpage is wrong/out of date. You are very welcome to 
> become the new maintainer, but let's not remove that message until we have 
> seen that you are staying with us
> 
> Anthony Fieroni wrote:
>     Ok. I will be the maintainer. I will add you to reviewer of my patches or 
> other guy?
> 
> Camilla Boemann wrote:
> put calligra as reviewer, however we are not really using this 
> reviewboard anymore, but rather phabricator instead
> 
> Anthony Fieroni wrote:
> So should i put this and other one patch in phabricator ?
> 
> Camilla Boemann wrote:
> no that is not needed - we allow many types of review - also in person or 
> via a mail - even in some cases self review
> 
> Anthony Fieroni wrote:
> Can we ship this, Arch (removed Karbon from git build), KaOS (removed it 
> entirely from repo)?

no not yet, but if you keep the fixes coming we can remove it right before 
release


- Camilla


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129421/#review100920
---


On Nov. 19, 2016, 7:38 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129421/
> ---
> 
> (Updated Nov. 19, 2016, 7:38 p.m.)
> 
> 
> Review request for Calligra, Camilla Boemann and Friedrich W. H. Kossebau.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> As https://community.kde.org/Calligra/Maintainers Karbon has a maintainer, so 
> i can be Co-Maintainer, i'm missing experience with graphics nor vector 
> graphics software but i will try to help and fixing bugs.
> 
> 
> Diffs
> -
> 
>   CalligraProducts.cmake 965e9d8 
> 
> Diff: https://git.reviewboard.kde.org/r/129421/diff/
> 
> 
> Testing
> ---
> 
> Builds.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129438: [karbon] Correct usage of KPageDialog in KarbonConfigureDialog.cpp

2016-11-20 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129438/#review100969
---


Ship it!




Ship It!

- Camilla Boemann


On Nov. 20, 2016, 9:42 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129438/
> ---
> 
> (Updated Nov. 20, 2016, 9:42 a.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Now config dialog saves changes correct, it's a porting script bug
> 
> 
> Diffs
> -
> 
>   karbon/ui/dialogs/KarbonConfigureDialog.cpp 0ba166d 
> 
> Diff: https://git.reviewboard.kde.org/r/129438/diff/
> 
> 
> Testing
> ---
> 
> Build and run with Karbon.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129437: [widgets] Make sure destination xml file path exist

2016-11-20 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129437/#review100968
---


Ship it!




Ship It!

- Camilla Boemann


On Nov. 20, 2016, 9:37 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129437/
> ---
> 
> (Updated Nov. 20, 2016, 9:37 a.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Otherwise it shown warning message ""Cannot write meta information to..."
> 
> 
> Diffs
> -
> 
>   libs/widgets/KoResourceServer.h 884e8ba 
>   libs/widgets/KoResourceTagStore.cpp 3ef0f4f 
> 
> Diff: https://git.reviewboard.kde.org/r/129437/diff/
> 
> 
> Testing
> ---
> 
> Build and run with Karbon.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129421: [karbon] Returning of Karbon as maintained product

2016-11-19 Thread Camilla Boemann


> On Nov. 17, 2016, 10:09 p.m., Camilla Boemann wrote:
> > It's great that you want to co maintain - i think you could even apply for 
> > maintaining without the "co-", but i also think it's a bit premature to 
> > remove that message. Maintain (be ambassador, fix bugs etc) for a month or 
> > so and if you are still warm about the idea we can remove the message.I 
> > mean the spot is yours if you want but make yourself a maintainer by deed 
> > before we make you one by name. Deal?
> > 
> > And just to emphazise it would be really great to see you work on karbon - 
> > it deserves to come to full glory!
> 
> Anthony Fieroni wrote:
> So you want to return warn message on non-Release builds?
> 
> Camilla Boemann wrote:
> I'm sorry I don't understand what you mean? Also karbon doesn't have a 
> maintainter. That webpage is wrong/out of date. You are very welcome to 
> become the new maintainer, but let's not remove that message until we have 
> seen that you are staying with us
> 
> Anthony Fieroni wrote:
>     Ok. I will be the maintainer. I will add you to reviewer of my patches or 
> other guy?
> 
> Camilla Boemann wrote:
> put calligra as reviewer, however we are not really using this 
> reviewboard anymore, but rather phabricator instead
> 
> Anthony Fieroni wrote:
> So should i put this and other one patch in phabricator ?

no that is not needed - we allow many types of review - also in person or via a 
mail - even in some cases self review


- Camilla


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129421/#review100920
---


On Nov. 19, 2016, 7:38 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129421/
> -------
> 
> (Updated Nov. 19, 2016, 7:38 p.m.)
> 
> 
> Review request for Calligra, Camilla Boemann and Friedrich W. H. Kossebau.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> As https://community.kde.org/Calligra/Maintainers Karbon has a maintainer, so 
> i can be Co-Maintainer, i'm missing experience with graphics nor vector 
> graphics software but i will try to help and fixing bugs.
> 
> 
> Diffs
> -
> 
>   CalligraProducts.cmake 965e9d8 
> 
> Diff: https://git.reviewboard.kde.org/r/129421/diff/
> 
> 
> Testing
> ---
> 
> Builds.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129435: [shapefiltereffects] Update ConvolveMatrixEffect kernel accordingly to order

2016-11-19 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129435/#review100953
---


Ship it!




Ship It!

- Camilla Boemann


On Nov. 19, 2016, 4:33 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129435/
> ---
> 
> (Updated Nov. 19, 2016, 4:33 p.m.)
> 
> 
> Review request for Calligra, Camilla Boemann, Friedrich W. H. Kossebau, and 
> Yue Liu.
> 
> 
> Bugs: 353816
> http://bugs.kde.org/show_bug.cgi?id=353816
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Added ability to save kernel changes by adding OK | Cancel buttons
> 
> 
> Diffs
> -
> 
>   plugins/shapefiltereffects/ConvolveMatrixEffectConfigWidget.cpp ef5b410 
> 
> Diff: https://git.reviewboard.kde.org/r/129435/diff/
> 
> 
> Testing
> ---
> 
> Build and run with Karbon
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129421: [karbon] Returning of Karbon as maintained product

2016-11-19 Thread Camilla Boemann


> On Nov. 17, 2016, 10:09 p.m., Camilla Boemann wrote:
> > It's great that you want to co maintain - i think you could even apply for 
> > maintaining without the "co-", but i also think it's a bit premature to 
> > remove that message. Maintain (be ambassador, fix bugs etc) for a month or 
> > so and if you are still warm about the idea we can remove the message.I 
> > mean the spot is yours if you want but make yourself a maintainer by deed 
> > before we make you one by name. Deal?
> > 
> > And just to emphazise it would be really great to see you work on karbon - 
> > it deserves to come to full glory!
> 
> Anthony Fieroni wrote:
> So you want to return warn message on non-Release builds?
> 
> Camilla Boemann wrote:
> I'm sorry I don't understand what you mean? Also karbon doesn't have a 
> maintainter. That webpage is wrong/out of date. You are very welcome to 
> become the new maintainer, but let's not remove that message until we have 
> seen that you are staying with us
> 
> Anthony Fieroni wrote:
> Ok. I will be the maintainer. I will add you to reviewer of my patches or 
> other guy?

put calligra as reviewer, however we are not really using this reviewboard 
anymore, but rather phabricator instead


- Camilla


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129421/#review100920
---


On Nov. 19, 2016, 7:38 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129421/
> -------
> 
> (Updated Nov. 19, 2016, 7:38 p.m.)
> 
> 
> Review request for Calligra, Camilla Boemann and Friedrich W. H. Kossebau.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> As https://community.kde.org/Calligra/Maintainers Karbon has a maintainer, so 
> i can be Co-Maintainer, i'm missing experience with graphics nor vector 
> graphics software but i will try to help and fixing bugs.
> 
> 
> Diffs
> -
> 
>   CalligraProducts.cmake 965e9d8 
> 
> Diff: https://git.reviewboard.kde.org/r/129421/diff/
> 
> 
> Testing
> ---
> 
> Builds.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129421: [karbon] Returning of Karbon as maintained product

2016-11-19 Thread Camilla Boemann


> On Nov. 17, 2016, 10:09 p.m., Camilla Boemann wrote:
> > It's great that you want to co maintain - i think you could even apply for 
> > maintaining without the "co-", but i also think it's a bit premature to 
> > remove that message. Maintain (be ambassador, fix bugs etc) for a month or 
> > so and if you are still warm about the idea we can remove the message.I 
> > mean the spot is yours if you want but make yourself a maintainer by deed 
> > before we make you one by name. Deal?
> > 
> > And just to emphazise it would be really great to see you work on karbon - 
> > it deserves to come to full glory!
> 
> Anthony Fieroni wrote:
> So you want to return warn message on non-Release builds?

I'm sorry I don't understand what you mean? Also karbon doesn't have a 
maintainter. That webpage is wrong/out of date. You are very welcome to become 
the new maintainer, but let's not remove that message until we have seen that 
you are staying with us


- Camilla


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129421/#review100920
---


On Nov. 17, 2016, 8:09 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129421/
> -------
> 
> (Updated Nov. 17, 2016, 8:09 p.m.)
> 
> 
> Review request for Calligra, Camilla Boemann and Friedrich W. H. Kossebau.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> As https://community.kde.org/Calligra/Maintainers Karbon has a maintainer, so 
> i can be Co-Maintainer, i'm missing experience with graphics nor vector 
> graphics software but i will try to help and fixing bugs.
> 
> 
> Diffs
> -
> 
>   CalligraProducts.cmake 965e9d8 
>   karbon/CMakeLists.txt ba775ad 
>   karbon/main.cpp 2fa3f4d 
>   karbon/ui/KarbonAboutData.h aa96ee1 
> 
> Diff: https://git.reviewboard.kde.org/r/129421/diff/
> 
> 
> Testing
> ---
> 
> Builds.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129421: [karbon] Returning of Karbon as maintained product

2016-11-17 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129421/#review100920
---



It's great that you want to co maintain - i think you could even apply for 
maintaining without the "co-", but i also think it's a bit premature to remove 
that message. Maintain (be ambassador, fix bugs etc) for a month or so and if 
you are still warm about the idea we can remove the message.I mean the spot is 
yours if you want but make yourself a maintainer by deed before we make you one 
by name. Deal?

And just to emphazise it would be really great to see you work on karbon - it 
deserves to come to full glory!

- Camilla Boemann


On Nov. 17, 2016, 8:09 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129421/
> ---
> 
> (Updated Nov. 17, 2016, 8:09 p.m.)
> 
> 
> Review request for Calligra, Camilla Boemann and Friedrich W. H. Kossebau.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> As https://community.kde.org/Calligra/Maintainers Karbon has a maintainer, so 
> i can be Co-Maintainer, i'm missing experience with graphics nor vector 
> graphics software but i will try to help and fixing bugs.
> 
> 
> Diffs
> -
> 
>   CalligraProducts.cmake 965e9d8 
>   karbon/CMakeLists.txt ba775ad 
>   karbon/main.cpp 2fa3f4d 
>   karbon/ui/KarbonAboutData.h aa96ee1 
> 
> Diff: https://git.reviewboard.kde.org/r/129421/diff/
> 
> 
> Testing
> ---
> 
> Builds.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



Re: Review Request 129420: [calligra] Remove obsolete typedefs, deprecated since Qt 5.7

2016-11-17 Thread Camilla Boemann

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129420/#review100915
---


Ship it!




Ship It!

- Camilla Boemann


On Nov. 17, 2016, 6:54 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129420/
> ---
> 
> (Updated Nov. 17, 2016, 6:54 p.m.)
> 
> 
> Review request for Calligra and Friedrich W. H. Kossebau.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> ^^
> 
> 
> Diffs
> -
> 
>   braindump/plugins/stateshape/CategorizedItemDelegate.cpp ad661c2 
>   libs/main/KoAutoSaveRecoveryDialog.cpp e543eaa 
>   libs/main/KoDocumentSectionDelegate.h ad4b9f1 
>   libs/main/KoDocumentSectionDelegate.cpp bcd7628 
>   libs/widgets/KoDockWidgetTitleBar.cpp 4d0d1aa 
>   plugins/textshape/dialogs/StylesCombo.cpp 9ca044b 
>   plugins/textshape/dialogs/StylesDelegate.cpp faa90fb 
> 
> Diff: https://git.reviewboard.kde.org/r/129420/diff/
> 
> 
> Testing
> ---
> 
> Build with Karbon.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>



RE: state of release and release plan

2016-11-14 Thread Camilla Boemann
Thanks Boud for the offer - much appreciated!

Dag let's try and get something out the sooner the better - even if it has
some known bugs that are not too serious -  it's the only way to create buzz
and hopefully draw in more volunteers

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of
Dag
Sent: 12. november 2016 10:45
To: Calligra Suite developers and users mailing list

Subject: Re: state of release and release plan

Boudewijn Rempt skrev den 2016-11-11 15:16:
> On Tue, 8 Nov 2016, Dag wrote:
> 
>> Ok, seems we have some sort of commitment from from Tomas, Camilla 
>> (separate
>> mail) and me,
>> which means Sheets, Words and Plan along with the shapes and filters 
>> we find is working.
>> 
>> But, I am totally blank on release work, so who will possibly step up 
>> to handle that?
> 
> With the createtarball.rb script in the kde-dev-scripts, it's so 
> easy-peasy to make a source release that I'm fine with doing that, for 
> old times' sake. I can also upload the source releases to the right 
> place in download.kde.org; I've got rights for that. I have no time to 
> make binary builds, but we never did that for Calligra anyway.
Thanks, that's very nice of you, Boudewijn.
It might take a bit of time still. With the amount of serious bug reports on
2.9.11, there is quite a bit of testing needed :(
> 
> What I don't see myself doing is writing the announcement for 
> calligra.org. If there's someone who volunteers for that, all that is 
> needed is to tell me when to branch, tag, generate the tarball and 
> upload the result.
Yes, well, we'll tackle it when we get there...




RE: Qt version

2016-08-10 Thread Camilla Boemann
My build machine (debian) is still 5.6 so until they are at 5.7 I cannot
agree to bumping higher than 5.6

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of
Dag
Sent: 10. august 2016 14:27
To: calligra-devel@kde.org
Subject: Qt version

I added a 5.7 specific thing recently, which prompts the question:
which qt version will be used in the release?

Cheers, Dag



RE: Plan status

2016-07-15 Thread Camilla Boemann
Have a nice vacation!

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of Dag
Sent: 15. juli 2016 14:10
To: calligra-devel@kde.org
Subject: Plan status

Vacation is going to hit soon, and plan is not ready...
It has been a frustrating week with too much time used on non-productive 
things, but progress *has* been made and I am fairly confident I will be able 
to have something mid august.

Regarding currency, does somebody know what is needed for sheets?
Plan doesn't need a lot, but I was thinking about lifting at least some of the 
code from kde4, if it isn't too much hassle.

Well, I'm off a couple of weeks, have a nice summer everybody!

See you,
Dag
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


Re: How to number components of Calligra 3

2016-07-03 Thread Camilla Boemann
On Sunday 03 July 2016 01:10:52 Jaroslaw Staniek wrote:
> How to number components of Calligra 3? I mean apps and libs.

Well I wouldn't mind dates or codenames for the public versioning, but 
versions numbers are also for internal usage, so we know when we make big 
api/code changes

And I see no reason why we should change our internal numbering to 4.x just 
because you make huge ui changes.

I would however be fine with us having a more user friendly version scheme in 
addition to our current numbering.

best regards
Camilla
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


Re: Introduction of a "type mode" and an "unicode mode" of input

2016-07-03 Thread Camilla Boemann
On Saturday 02 July 2016 21:18:05 Samiur Rahman wrote:
> The box should actually say "“Choose character set."

Definitely not. We use unicode and nothing else. We want to support the entire 
world. But we don't ship fonts and we don't provide input methods for other 
languages. Both tasks fall under the responsibility of the OS and user. We 
don't ship western fonts either mind you.

I feel that you mean something else like a way to select several "current 
fonts" rather than just a single font. And a way to assign what unicode range 
uses what font. Such multifont selection is only useful when you mix different 
scripts but maybe that is what you mean?'

best regards
Camilla


___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


  1   2   >