[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Status of KoMacro ?
From:       Thomas Zander <zander () kde ! org>
Date:       2007-05-20 14:10:53
Message-ID: 200705201610.53257.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 20 May 2007 15:40:04 Cyrille Berger wrote:
> > >  - security: it's much more harder to secure python/ruby than a
[]>
> I think you are giving to much credit to Kross :) And to the
> interpreters :)

We choose python specifically for its ability to do sandboxing.
I would also think we allow ssl and/or gpg for the peer-to-peer connection 
so you don't end up sharing your drawing with bill gates or mr evil 
hacker sr.
At the same time I have to return the favor; you are going too much credit 
to your C++ code that can parse whatever the other party is sending 
without security problems ;)

> > > That's why I much preffer my solution (see
> > > http://wiki.koffice.org/index.php?title=Image:ActionsRecordingKrita
> > >.png ) where "exporting to script" is just a plugin at the end.
> >
> > Sure, if that's how you want to do it, I won't stop you.
>
> Especially that I would have need a slave to write and maintain the
> python output ;) 

I can't imagine that being a big stumbling block.  Its not like you have 
to write for loops or even more complex things.  The 
plugins/viewplugins/scripting/scripts/reshapehisto.py is horribly complex 
in comparison.
I expect the output to be a series of simple commands that directly map to 
the exported commandset from krita.

The extend of the macro file would probably be limited to trivial commands 
like;
  layer.rotateImage(centerx: 100, centery: 100, angle: 43.82);

> While XML and C++ is common knowledge. Now the  
> problem is that if I do my way and all koffice developers think it
> should be done otherwise, then later someone will come up with a
> different solution, and my work will be thrown away and my time wasted
> :) Now the question is, would you accept to use a framework that can do
> more, but that you can use for less in KWord ?

My plan to have a macro framework like I described has not changed. If you 
intend to implement yours the way you described it will most likely mean 
I won't (try to) use it in KWord and keep on pushing for a komacro 
package based on kross.
The basic design would be so different that we really are talking about 
two different solutions to the same problem on all levels.  Where I view 
the solution based on scripts to be much more usable for a wider range of 
people and solutions as well as directly in line with a coarse we set out 
to sail over a 2 years ago by choosing kross.

I have to say I would like you to work on furthering the common libraries, 
but I know that you have to make your own choice.

Cheers
-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]