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

List:       koffice-devel
Subject:    Fwd: Re: About 2.0
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2006-03-24 18:08:58
Message-ID: 200603241908.58761.mail () dipe ! org
[Download RAW message or body]

Boudewijn Rempt wrote:
> *** Pervasive scripting using Kross
>
> Already Isaac has started on a Kross plugin for KSpread. We really should
> push this along and integrate into KWord, KPresenter and all our other
> applications. Note: look for ways to call two applications from one
> Kross scripts. Or maybe that's already possible.

Yes, that's already possible as it's possible to use functionality (as in 
bindings like we have for kexidb) without starting the application itself. 
So, once the KSpread-binding is in shape, it shouldn't be that difficult to 
have e.g. a python script that use both, kexi and kspread, to archive 
whatever the script likes to archive.

> *** IPC interpreter plugin for Kross
>
> That way we have to define the scripting interface only once and have
> a common api for scripting and ipc. And we can get rid of the individual
> IPC definitions that are littering the individual applications and are
> never complete or coordinated.
[...]
>> So the question is, can
>> you do something like that with dbus/dcop :
>>
>> image = Dcop/Dbus::call("Krita Kross Document getImage");
>> and then manipulate the image object ?

That's possible by using DCOPRef-objects. Qt's introspection-functionality 
could be used to provide access to signals and slots and since it's not that 
difficult to have a 'dynamic QObject' that builds it's signals and slots on 
runtime, I currently don't see problems on providing such a dcop-backend (in 
fact KoMacro already has some code in for building QObject's+signals+slots on 
runtime). But I've to add, that I don't know about the new dbus-ipc and it's 
flexibility/functionality/needings/etc. yet...

> *** Macro recorder
>
> KoMacro is already in playground, but I don't know about its status.

Current status is, that we have now a team of 4 developers that will work on
KoMacro next 3-4 months. It is a project we develop at my university as part
of our so named 'softwareproject'. Since the other 3 devels are java-coders
and therefore will need some Qt-instructions I'll provide and since we need
to follow the wishes of our Professor, we have a lot of overhead.
That results in very limited goals we defined. So, on the one hand it's
currently heavily based on Qt3 (but it was designed in mind with a port to
Qt4 later this year), follows the definition of Macros as Kexi and e.g.
wikipedia defines them (see link at the bottom, Macros as batch-processor to
automate tasks) and doesn't include a 'Macro-recorder' yet (the most
difficult part here is, that it's needed to (un-)serialize e.g.
dialog-settings to be able to reproduce them).
Our main goal is to include it in Kexi till beginning of september, so it  
will be part of 1.6. Even if that's the goal and anything beside that isn't, 
we already took care of making it reusable as lib for other ko-apps. So, 
maybe one day it could go the same way Kross went; Kexi=>KoLib. But I am not 
sure it's ready for such a move this year.

http://www.kexi-project.org/wiki/wikiview/index.php?Macros

--
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org
_______________________________________________
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]