> On Feb. 16, 2015, 11:11 a.m., Inge Wallin wrote:
> > Wouldn't a much better solution be to make the Private class of the
> > KoMarker shared? If so, we could have the collection store KoMarkers
> > instead of a collection of KoMarker*s. Making KoMarker itself a QSharedData
> > feels very str
> On Feb. 16, 2015, 10:11 a.m., Inge Wallin wrote:
> > Wouldn't a much better solution be to make the Private class of the
> > KoMarker shared? If so, we could have the collection store KoMarkers
> > instead of a collection of KoMarker*s. Making KoMarker itself a QSharedData
> > feels very str
> On Feb. 16, 2015, 11:11 a.m., Inge Wallin wrote:
> > Wouldn't a much better solution be to make the Private class of the
> > KoMarker shared? If so, we could have the collection store KoMarkers
> > instead of a collection of KoMarker*s. Making KoMarker itself a QSharedData
> > feels very str
For kexi reports I'd like to try out qjsengine. It looks closest to qtscript,
which is the only Kross engine I ever really tested.
Js is easy to pickup and powerful enough for our uses I think.
Sent from my BlackBerry 10 smartphone.
Original Message
From: Jaroslaw Staniek
Sent: Monday, 16 Fe
On 16 February 2015 at 12:56, Robert Leleu wrote:
> I'd rather use Python which seems actively developed, and seems to be the
> most easily usable by non-programmer people (my experience)
Knowing Python, it's my personal choice too. However too bad it's
official: Due to its architecture Python ca
> On Feb. 16, 2015, 10:11 vorm., Inge Wallin wrote:
> > Wouldn't a much better solution be to make the Private class of the
> > KoMarker shared? If so, we could have the collection store KoMarkers
> > instead of a collection of KoMarker*s. Making KoMarker itself a QSharedData
> > feels very st
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122584/#review76108
---
Wouldn't a much better solution be to make the Private class o
On Mon, 16 Feb 2015, Jaroslaw Staniek wrote:
On 16 February 2015 at 10:28, Boudewijn Rempt wrote:
On Mon, 16 Feb 2015, Jaroslaw Staniek wrote:
As you know KROSS isn't in KF5/Qt5, so it's not an option to re-add
it. Moreover the idea of KROSS was a general one-size-fits-all support
for multip
On 16 February 2015 at 10:45, Tomas Mecir wrote:
> I've no idea what state it is in, but, what about KJS/KJSEmbed?
> http://api.kde.org/frameworks-api/frameworks5-apidocs/kjs/html/index.html
This is a plain engine. No idea how updated compared to Qt's one.
> http://api.kde.org/frameworks-api/fra
On 16 February 2015 at 10:28, Boudewijn Rempt wrote:
> On Mon, 16 Feb 2015, Jaroslaw Staniek wrote:
>
>> As you know KROSS isn't in KF5/Qt5, so it's not an option to re-add
>> it. Moreover the idea of KROSS was a general one-size-fits-all support
>> for multiple programming languages, without find
I've no idea what state it is in, but, what about KJS/KJSEmbed?
http://api.kde.org/frameworks-api/frameworks5-apidocs/kjs/html/index.html
http://api.kde.org/frameworks-api/frameworks5-apidocs/kjsembed/html/index.html
2015-02-16 10:19 GMT+01:00 Jaroslaw Staniek :
> Hi,
> As you know a semi-offici
On Mon, 16 Feb 2015, Jaroslaw Staniek wrote:
As you know KROSS isn't in KF5/Qt5, so it's not an option to re-add
it. Moreover the idea of KROSS was a general one-size-fits-all support
for multiple programming languages, without find-grained support for
specifics of given language. For example yo
Hi,
As you know a semi-official conclusion is that we can afford
development of scripting for at most one scripting language, and for
some reasons like popularity and security it's JavaScript. [0]
I am forwarding the thread from the developm...@qt-project.org list. [1]
(CC'd to calligra-devel sin
13 matches
Mail list logo
