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

List:       koffice-devel
Subject:    Re: KPlato questions
From:       Dag Andersen <danders () get2net ! dk>
Date:       2010-11-02 14:29:11
Message-ID: 201011021529.11630.danders () get2net ! dk
[Download RAW message or body]

Tirsdag 02 november 2010 06:05:30 skrev Dmitry Makovey:
> Dag, thank you very much for your answers, see in-line...
> 
> On 11/01/2010 02:12 AM, Dag Andersen wrote:
> > You should be able to select which scheduler to use in Scheduler
> > column in the
> > Schedule view.
> > If you don't have a "RCPS Scheduler" entry there something isn't right.
> > A possibility is that sycoca hasn't picked up the plugin desktop file.
> > You can test that by running:
> > kbuildsycoca4
> > kplato&
> > from a terminal.
> 
> my problem seemed to be more of a PEBKAC problem after all - default
> layout did not include "scheduler" field, tinkering with it a bit
> allowed me to change scheduler and get desired results. Thank you.
Good.
> 
> >> 2. Is there a documentation on plugin building for KPlato or at least
> >> some standalone sample.
> > 
> > Sorry, no docs, the only implementation is the rcps plugin. You can find
> > the source in kplato/plugins/schedulers/rcps.
> 
> the rcps plugin is rather involved and requires knowledge of both
> librcps and kplato internal structures. However I have made some
> progress hacking my way through and I think I have narrowed down the
> area for a possible patch. Seeing that your name pops up in KPlato
> sources - I'd like to ask whether present behavior is expected and
> desired or was it an omission? Reason I'm asking is that I can try to
> patch things up a bit to suit my needs and provide you with the patch
> which may turn out to be crude implementation or I can just patch my
> local install and hold off on further requests until things shake down a
> bit with koffice direction and KPlato internals. The easiest way for me
> to patch it is to change RCPS behavior by feeding it slightly altered
> data (shifting effort value by the actualEffort delta or use
> task->comletion()->remainingEffort instead of  task->estimate and
> possibly shifting entire start/end by appliedEffort delta if I can;
> above is subject to further investigation). But that means that I lose
> original RCPS behaviour - slightly better implementation would be to add
> a boolean value controlling behaviour - "Use applied effort" or
> something like it, but that is definitely out of my current skill range.
This is a bug. It should have used remainingEffort() as you noted above.
Fixed in trunk.
> 
> >> I have some very specific problem (
> >> http://forum.kde.org/viewtopic.php?f=96&t=91177 ) and my feeling is that
> >> I may have to dig into scheduler to make it do what I need, however I
> >> haven't done much C/C++ lately (let alone KDE/Qt development in those
> >> languages) so if possible I'd rather tackle it from Python,
> > 
> > The existing rcps plugin is c++, I don't know how difficult it would be
> > to interface a scripting language.
> 
> My thinking was more along the lines - "can I build entire scheduling
> plugin in Python?" but I'm guessing it's not possible just yet.
No, somebody needs to implement the c++ part first...
> 
> > Note that headers for the needed kplato libraries are not installed as
> > they are not in a shape for third party development.
> 
> Is there a schedule for stabilization of those or some other ways of
> determining how far or close is implementation that is stable and fit
> for third party development? (asking for a very selfish reasons - hoping
> somebody better skilled than me will pick up and build needed plugins
> based on above ideas :) )
Well, no, there are so many other things todo, so we can only hope :)
-- 
Mvh.
Dag Andersen
_______________________________________________
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]