Re: Releasing 2.9.11

2016-01-21 Thread Jaroslaw Staniek 
OK,
According to agreement made on IRC:

Jan 30th - tagging
Feb 3rd - release


On 12 January 2016 at 10:11, Jaroslaw Staniek  wrote:

> On 12 January 2016 at 08:53, Boudewijn Rempt  wrote:
> > Yes, I will definitely have bug fixes, and also updated French
> translations
> > that should coincide with the publication of the first Krita book in
> French.
>
> Wonderful, things go just right! More and more bug fixes here for Kexi too.
>
> >
> > On Fri, 8 Jan 2016, Jaroslaw Staniek wrote:
> >
> >> On 5 January 2016 at 07:30, Boudewijn Rempt  wrote:
> >>>
> >>> On Mon, 4 Jan 2016, Jaroslaw Staniek wrote:
> >>>
>  On 4 January 2016 at 12:15, Boudewijn Rempt  wrote:
> >
> >
> > On Mon, 4 Jan 2016, Jaroslaw Staniek wrote:
> >
> >> Hi All,
> >> Are we ready to release 2.9.11?
> >>
> 
>  How about tagging near 16 or 23 or 30 Jan?
>  Do you expect any fixes by then?
>  Kexi will have 2 fixes at least.
> 
>  Next date that fits to my availability would be Feb 13th.
> 
> >>>
> >>> Right now, I cannot promise anything -- I first need to finish working
> >>> packages of 3.0 alpha!
> >>
> >>
> >> Noted, you have full 3 weeks for that :)
> >>
> >>
> >> --
> >> 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
> >> ___
> >> calligra-devel mailing list
> >> calligra-devel@kde.org
> >> https://mail.kde.org/mailman/listinfo/calligra-devel
> >
> >
> > --
> > Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
> > ___
> > calligra-devel mailing list
> > calligra-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
>
> --
> 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
>



-- 
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
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request 124630: Use SHARE_INSTALL_PREFIX instead of {INSTALL_PREFIX, }share

2016-01-21 Thread Friedrich W. H. Kossebau 

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



Given the appdata file installation rules seem to use SHARE_INSTALL_PREFIX with 
success, seems to be an acceptable var :)

But I have no idea how the var works for windows, osx and other non-linuxoid 
platforms.
@boud, can you tell, given this is mainly about things installed by krita?

- Friedrich W. H. Kossebau


On Sept. 8, 2015, 7:05 p.m., Heiko Becker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124630/
> ---
> 
> (Updated Sept. 8, 2015, 7:05 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Allowing to configure the install location, which is helpful with a
> multiarch layout, where prefix might be something like /usr/ but
> arch independent data should be installed to /usr/share/...
> 
> 
> Diffs
> -
> 
>   active/CMakeLists.txt 8fa0c6f 
>   krita/data/profiles/CMakeLists.txt a2a997b 
>   krita/data/profiles/elles-icc-profiles/CMakeLists.txt 8aa5a83 
> 
> Diff: https://git.reviewboard.kde.org/r/124630/diff/
> 
> 
> Testing
> ---
> 
> tquiChecked that the affected files get installed into the desired location.
> 
> 
> Thanks,
> 
> Heiko Becker
> 
>

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

Re: Review Request 122153: KD Chart

2016-01-21 Thread Friedrich W. H. Kossebau 


> On Jan. 16, 2016, 12:31 a.m., Jarosław Staniek wrote:
> > @Friedrich What to do with this patch? Is it needed now or?

Guess so. Still missing proper sets of files/data to test it, so can only 
blindly commit it, but perhaps better than to ignore. Will do in the next days.


- Friedrich W. H.


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


On Dec. 3, 2015, 7:58 a.m., Stephen Leibowitz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122153/
> ---
> 
> (Updated Dec. 3, 2015, 7:58 a.m.)
> 
> 
> Review request for Calligra and Jarosław Staniek.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> These patches are also being made at kdab.com. Those who have a KDAB account 
> can see the discussion in “Suggested Changes to KD Chart” at 
> https://quality.kdab.com/browse/KDCH-1020
> 
> Calligra’s kdchart and kdgantt files are out-of-date, even with the patches 
> from the above paragraph. For example, “Compiler warnings” at
> http://mail.kde.org/pipermail/calligra-devel/2015-January/012762.html
> mentioned an error in KDChartPieDiagram.cpp. But the error is in a private 
> function that was removed from the latest version (2.5.1) of KD Chart. KDAB 
> will not patch previous versions. See “PieDiagram::drawPieSurface” at
> https://quality.kdab.com/browse/KDCH-1023
> 
> KDAB makes available source code for the latest and earlier versions of its 
> KD Chart and other GPL licensed software at http://docs.kdab.com/
> 
> 
> Diffs
> -
> 
>   3rdparty/kdchart/src/KDChartLayoutItems.cpp 095d2cd 
>   3rdparty/kdchart/src/KDChartStockDiagram_p.cpp d8636d7 
> 
> Diff: https://git.reviewboard.kde.org/r/122153/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Stephen Leibowitz
> 
>

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

Re: [Sheets] Python Console Docker

2016-01-21 Thread Jaroslaw Staniek 
On 21 January 2016 at 05:44, David Narvaez 
wrote:

> Hi,
>
> I was very excited to see there was a Python console docker in Sheets,
> only to find that it does not work. I tried to get it back in shape and I
> have a couple of patches, plus a couple of roadblocks that I would like to
> discuss in this list. For patches, is Review Board still the way to go as
> described in [0]? Also, is anybody else working on Python scripting in
> Sheets right now?
>

​Short answer, not many commits for that, even dedicated maintainer
probably welcome, no special interest resulting in real coding, and
especially, organized design.

Longer answer require showing more context.

​I can first mention atmosphere around Python and scripting in general
closer to the Kexi circles.​

​But I believe since the intent is to have consistent scripting in the
future, it somehow helps to see some relation to Sheets, being in the same
class of apps.
​

​As some people may know I like Python for its purposes. KDE even started
(in Calligra) projects such as Kross to support more languages honestly.
This support was were means for not too deep bindings, not
language-specific, rather calling methods of objects without much regard to
integration with data types or language specifics.

As a part of general 'cleanup' Kexi 3 removes Kross usage and moves towards
a single language-solution that happens to be JavaScript, using QtQml. The
main reason is that sandbox works there and not in Python.[1] By default
QtQml gives no tiny chance to access filesystem for example or run unwanted
scripts.

There are no declared lovers of JavaScript among us, C++ hackers I think.
But the specifics of JavaScript is less of a problem than inherent
insecurity of Python's execution environment. Insecurity would manifest
once apps that use scripts get popular. The result I'd expect is very much
like perfect cross-platforms viruses.
This is possible if scripts are accessible with documents, which is
assumption of Kexi (files are meant to be user-defined apps) and in the
future, I believe, also Sheet's documents, if we want competitiveness.

For that matter, also ruby and bash and perl, would be all better rejected
for the same reason.
Sure, there were ideas of digital signing of scripts but 1. Even tech
people do not use that (and even for emails) in general, 2. Except for
Krita "official" builds we're not controlling the deployment process,
distros do that, and I imagine all sort of critical issues can sooner
happen e.g. because of mixes responsibility. It seems that distros are able
to act more "reactionary", not as  "owners" of the software as a product.
Which does not surprise me and there's nothing to criticize.
​
For Kexi <=2 (no matter what language is picked) scripting is marked as
having experimental status. I am not sure whether this is the case for
Sheets too but for Kexi there's because of such honest status we can assume
there's no disservice to users. With Kexi 3 we have ability to start fresh
and with knowledge/experience gathered in the past. Also about knowledge
about the user base.

For some other contexts the choice scripting can depend on external
requirements. Like "industry" standards -- for Krita Python is perceived as
some kind of standard for extending graphical features. Similar opinion
applies for Krita itself - generic calligra-wide scripting never have been
too actively maintained and was Kross is too simple, see [2]. For the
record, Krita has a proof-of-concept implementation of scripting in a
separate repo.

[1] Google for "Python sandbox" for detailed discussion from Python hackers
on why this is not possible and dropped idea.
[2] https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html


> Thanks.
>
> David E. Narvaez
>
> [0] https://community.kde.org/Calligra/Contributing_a_Patch
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>


-- 
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
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Heads-up: kdesrc-build should now work better with kexi & krita repos, calligra repo changed position

2016-01-21 Thread Friedrich W. H. Kossebau 
Hi,

if you are using kdesrc-build with kexi & krita or would like to use it, 
things should work better now due to some adaptions in the KDE repo metadata 
structure, i.e. no longer result in also the calligra repo being fetched and 
build in some cases or the krita/kexi sources being mixed into the calligra 
sources.

Those using kdesrc-build for the calligra repo, please take into account that 
the position of the calligra repo has now moved from "calligra/" to 
"calligra/calligra/", thus can also result in calligra source and build dir 
now being different on your storage system (perhaps unless you configured 
things explicitely, no expert).

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

Re: Review Request 122153: KD Chart

2016-01-21 Thread Stephen Leibowitz 


> On Jan. 16, 2016, 12:31 a.m., Jarosław Staniek wrote:
> > @Friedrich What to do with this patch? Is it needed now or?
> 
> Friedrich W. H. Kossebau wrote:
> Guess so. Still missing proper sets of files/data to test it, so can only 
> blindly commit it, but perhaps better than to ignore. Will do in the next 
> days.

I submitted the patch last year. I first submitted it to kdab.com, where it 
became issue KDCH-1020. The Status there is CLOSED, and the Resolution is 
FIXED. The Assignee was KDAB staffer Andreas Hartmetz. Here is his final 
comment, dated 14/Jan/15:

“I've changed the h/v line layout items to only grow in the lengthwise 
direction and removed the comments. The comments didn't add anything of value. 
I've also changed "< 360" to "<= 360". The latter is more consistent with line 
211 and also with the previous if condition, which is inclusive at the edges of 
the value range (0...360). It should not change the behavior at all, due to 
reversedOrder = false by default. Well, actually the whole if and dependent 
code is redundant, it's really just documentation.”

Andreas said, “I've also changed "< 360" to "<= 360".”
I (Stephen) first suggested to kdab.com that "< 0" be changed to "< 360". I 
then slightly modified my suggestion to "<= 360". Here are the original and 
changed lines:
if ( ( angle >= 90 && angle < 180 ) || ( angle >= 270 && angle < 0 ) )
*change to*:
if ( ( angle >= 90 && angle < 180 ) || ( angle >= 270 && angle <= 360 ) )

Andreas mentioned line 211 in his comment. Here is the line:
} else if ( angle >= 270.0 && angle <= 360.0 ) {

Their line 211 corresponds to line 209 in Calligra’s repository at
https://projects.kde.org/projects/calligra/calligra/repository/entry/3rdparty/kdchart/src/KDChartStockDiagram_p.cpp?rev=calligra%2F2.9


- Stephen


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


On Dec. 3, 2015, 7:58 a.m., Stephen Leibowitz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122153/
> ---
> 
> (Updated Dec. 3, 2015, 7:58 a.m.)
> 
> 
> Review request for Calligra and Jarosław Staniek.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> These patches are also being made at kdab.com. Those who have a KDAB account 
> can see the discussion in “Suggested Changes to KD Chart” at 
> https://quality.kdab.com/browse/KDCH-1020
> 
> Calligra’s kdchart and kdgantt files are out-of-date, even with the patches 
> from the above paragraph. For example, “Compiler warnings” at
> http://mail.kde.org/pipermail/calligra-devel/2015-January/012762.html
> mentioned an error in KDChartPieDiagram.cpp. But the error is in a private 
> function that was removed from the latest version (2.5.1) of KD Chart. KDAB 
> will not patch previous versions. See “PieDiagram::drawPieSurface” at
> https://quality.kdab.com/browse/KDCH-1023
> 
> KDAB makes available source code for the latest and earlier versions of its 
> KD Chart and other GPL licensed software at http://docs.kdab.com/
> 
> 
> Diffs
> -
> 
>   3rdparty/kdchart/src/KDChartLayoutItems.cpp 095d2cd 
>   3rdparty/kdchart/src/KDChartStockDiagram_p.cpp d8636d7 
> 
> Diff: https://git.reviewboard.kde.org/r/122153/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Stephen Leibowitz
> 
>

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

Re: [Sheets] Python Console Docker

2016-01-21 Thread David Narvaez 
On Thu, Jan 21, 2016 at 4:26 AM, Friedrich W. H. Kossebau
 wrote:
> Hi David,
>
> Am Mittwoch, 20. Januar 2016, 23:44:13 schrieb David Narvaez:
>> I was very excited to see there was a Python console docker in Sheets, only
>> to find that it does not work. I tried to get it back in shape and I have a
>> couple of patches, plus a couple of roadblocks that I would like to discuss
>> in this list. For patches, is Review Board still the way to go as described
>> in [0]?
>
> Review board still works, but better use Phabricator. I will update the wiki
> page, thanks for the hint.

While you are at it, you may want to update the First Contact page
too[0], it still mentiosn KDEDIRS etc. In my case, I only had to set
the XDG_DATA_DIRS environment variable.

David E. Narvaez

[0] https://community.kde.org/Calligra/First_Contact
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [Sheets] Python Console Docker

2016-01-21 Thread David Narvaez 
On Thu, Jan 21, 2016 at 3:59 AM, Jaroslaw Staniek  wrote:
> Short answer, not many commits for that, even dedicated maintainer probably
> welcome, no special interest resulting in real coding, and especially,
> organized design.
>
> Longer answer require showing more context.
>
> I can first mention atmosphere around Python and scripting in general closer
> to the Kexi circles.
>
> But I believe since the intent is to have consistent scripting in the
> future, it somehow helps to see some relation to Sheets, being in the same
> class of apps.
>
> As some people may know I like Python for its purposes. KDE even started (in
> Calligra) projects such as Kross to support more languages honestly. This
> support was were means for not too deep bindings, not language-specific,
> rather calling methods of objects without much regard to integration with
> data types or language specifics.
>
> As a part of general 'cleanup' Kexi 3 removes Kross usage and moves towards
> a single language-solution that happens to be JavaScript, using QtQml. The
> main reason is that sandbox works there and not in Python.[1] By default
> QtQml gives no tiny chance to access filesystem for example or run unwanted
> scripts.
>
> There are no declared lovers of JavaScript among us, C++ hackers I think.
> But the specifics of JavaScript is less of a problem than inherent
> insecurity of Python's execution environment. Insecurity would manifest once
> apps that use scripts get popular. The result I'd expect is very much like
> perfect cross-platforms viruses.
> This is possible if scripts are accessible with documents, which is
> assumption of Kexi (files are meant to be user-defined apps) and in the
> future, I believe, also Sheet's documents, if we want competitiveness.
>
> For that matter, also ruby and bash and perl, would be all better rejected
> for the same reason.
> Sure, there were ideas of digital signing of scripts but 1. Even tech people
> do not use that (and even for emails) in general, 2. Except for Krita
> "official" builds we're not controlling the deployment process, distros do
> that, and I imagine all sort of critical issues can sooner happen e.g.
> because of mixes responsibility. It seems that distros are able to act more
> "reactionary", not as  "owners" of the software as a product. Which does not
> surprise me and there's nothing to criticize.
>
> For Kexi <=2 (no matter what language is picked) scripting is marked as
> having experimental status. I am not sure whether this is the case for
> Sheets too but for Kexi there's because of such honest status we can assume
> there's no disservice to users. With Kexi 3 we have ability to start fresh
> and with knowledge/experience gathered in the past. Also about knowledge
> about the user base.
>
> For some other contexts the choice scripting can depend on external
> requirements. Like "industry" standards -- for Krita Python is perceived as
> some kind of standard for extending graphical features. Similar opinion
> applies for Krita itself - generic calligra-wide scripting never have been
> too actively maintained and was Kross is too simple, see [2]. For the
> record, Krita has a proof-of-concept implementation of scripting in a
> separate repo.
>
> [1] Google for "Python sandbox" for detailed discussion from Python hackers
> on why this is not possible and dropped idea.
> [2] https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html

Ditching Python because of sandboxing issues makes sense. That being
said, I would use Python to access the file system from my
spreadsheets all the time. I don't really remember what made me to
look into scripting support in Sheets but I vaguely remember something
merging several CSVs into a single spreadsheet.

In any case, if the current plan is to remove Python support, I guess
I am better off working on removing that instead of fixing it,
correct?

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