Hi again all, Thanks again Lincoln for the testing and "mentoring" I read the comments in the doco about giving cvs diff the "-u", unfortunately "cvs diff" is one of those lines that I type subconsciously. Sorry about that Richard. Anyhow, thanks for picking up the problem, the attached patch fixes it(i think) but I am not sure that it is an ideal way. When the relation type is changed, I delete the relation and re-insert it. Which actually is the same thing that is done if the predecessor is changed. With my lack of gtk programming it took me a while to traverse the entire link of function calls and signals that link the user request(dialog box) and user output(draw the arrow). By this time I was happy just to get a working solution. The alternative is to implement a bunch functions calls, signals, slots in parallel to the ones that get called when a relation is added or removed. This would add functionality to "change" a relation type. While this seems slightly architecturally "cleaner" to me, it is a bunch more work and would just increase complexity to about 5 interfaces. i.e. the KISS principle opposes this. So what is the general consensus on this kind of question. I know in my usual commercial environment(at work) we would favour the current implementation as development time is something that we always try to optimise. I am quite happy to implement it the other way, but perhaps that time could be better spent doing something else. Of course if there is a deeper problem with this implementation then I should re-do it regardless. Thanks guys. On Sat, 3 Apr 2004 04:06 pm, you wrote: > Corey, > > firstly.... > > Create two tasks, Go into task number two and then add a SS > predecessor to task 1. Gantt updates as expected. Now change > this within the task dialog to any other and you'll see that > the gantt doesn't change the link line and arrows. > > I've seen this before when I was changing the Resource > allocated percentage and the gantt didn't update and I had to > tweak some extra code. Your's may be a similar issue. > > Richard (of Imendio) will pick up the patch, check it, > and then tweak if neccessary, or comment on how it needs to be > changed, and if OK merge it in to the GNOME CVS. > > It takes a few hours for this to appear in anon cvs (which > is what I use). I use the changelog file to see if this has > updated when I'm waiting for anon cvs to get in sync with > main GNOME cvs. > > The main comment I have on the presentation of the patch is that > he likes the diff format to be -u and no whitespace (-b -B) > and to include the c function in each section (-p). Thus I use ..... > > cd myplannersandbox > cvs diff -ubBp 1>../mydifffile.diff > > then tar.gz (planner-dev has a 40kbyte limit on postings) or > email that diff to the planner-dev. If you are using Cervisia > then that doesn't yet do the diff to repository right. I've > emailed the Cervisia developer and I'd hope to see > a new version of Cervisia with such a new feature but not yet. > > Before I ship my patches I also re-verify that the patch > can be applied to a clean checkout of anon CVS. > > Actually on your patch applies OK - I reverted my copy of > planner-relation-arrow.c, planner-relation-arrow.h > and mrp-task-manager.c to undo your previous patches you > emailed and applied this pred_types_update.diff fine, well > other that the comments above on how gantt handles on-the-fly > changes to the dialog entry :) > > > Rgds, > Lincoln > (another Planner contributor). > > Corey Schuhen wrote: > > Hi again, > > > > Thanks for your comments. I have done some more work on the other predecessor > > types. I farmed the "compute min time for a particular predecessor > > relationsship" into a separate function. I have also implemented (what I > > think) the correct drawing of arrows in the gantt chart, let me know if you > > all think this is how they should work. It would also be nice to make sure > > that no lines were drawn through other tasks, but that might be a bit more > > work. > > > > New screenshot and cvs diff attached. Look at my last one to see what has > > changed. > > > > Anyway, assuming this all looks good... how do I go about getting it > > committed to CVS? What process does it have to go through. > > > > Cyas, > > > > Corey > > > > > > > > > -- -- Corey Schuhen corey_m schuhen net http://schuhen.net
Attachment:
pred_types_update2.diff.gz
Description: GNU Zip compressed data