Re: KPlato questions
Dag Andersen <[email protected]>
| Newsgroups | gmane.comp.kde.devel.koffice |
|---|---|
| Message-ID | <[email protected]> |
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