I can see the UML objects are all copied from each other, Activity in particular
is copied quite directly from state.c

I compared activity.c to state.c and again compared activity.c to actor.c 

I added in various Props and tried various different things, and I went so far
as to change all the references to state in activity.c and replace them with
Activity|activity|ACTIVITY.  (In my last efforts I tried 'make clean' and
rebuilding from scratch but unsuprisingly that didn't help either.)

In spite of my efforts (over two hours) I'm still missing a trick and I have not
figured out how to get the Activity Object to properly inherit the foreground
and background colours like the State and Actor objects already do. 

this might still be an easy-fix for someone who knows what they are doing but
I'm stumped.  I'm also tired and hungry so I'm giving up for now.  Suggestions
welcome, patches even more so.   


I've just noticed that there are other UML object that do not use the foreground
and background colours properly either:
Aggregation, Facet, Recepticle, Event Source, Event Sink, Initial/End State,
Fork Union.  

Hopefully this extra infromation will help me figure out later what exactly the
differences are (but suggestions are still very welcome) and get these and any
other objects working a bit more consistently.  

We want easy-fix to be used when either they are willing to help beginners fix
the code, or else are sufficiently familiar with the code to know that beginners
ought to be able to handle it by themselves.  (Note that I just recently updated
the description of the keyword to reflect this.)  I'm guessing from your
struggles that this isn't the case.  Also, we're nuking HELPWANTED altogether
soon since it just clutters things, so I'll remove those keywords...

Alan, make sure to remove your defaults.dia file from ~/.dia when doing work on defaults, or else 
the defaults may well be taken from there instead.

Thanks for the advice Lars, hopefully I'll have time to give it another try this
weekend.  

Elijah.  I'm an awful programmer and a terrible judge of what really constitutes
an easy-fix (which I thought this should be as most of the UML objects are
extremely similar).  I've never really learnt C and although I know a fair bit
of computer science I'm mostly just doing what I call cut and paste coding. 

The HELPWANTED keyword is pretty redundant, what kind of messed up open source
project doesn't want help?  By opening the source in the first place the
implication is that you do want other people to get involved (although the
arrogance of some duhvelopers makes it seem like they dont want any help).  

In case anyone is intersted here is the file I ended up with, there should only
are only be about 10-20 lines worth of important changes.  Most of the changes
are from replacing the word state with actitivity and it would be helpful if
someone could let me know if should start over from a clean version of
activity.c or keep the version without the references to state.  
http://www.maths.tcd.ie/~horkana/dia/activity.c

When I go through the UML objects, I see several that don't obey the user-set
colors:

Association
Aggregation
Facet
Receptacle
Event Source
Event Sink
Initial/End State
Fork/Union
Transition

Activity is ok, though.

nevermind, activity was filed and fixed in bug 163260
It is shame that patches like that get applied in just one place without any
meta bug being opened about fixing it in the rest of the codebase as it would
make for some relatively easy tasks for me to do while getting to know the code
better.  (I guess I'll have to review some of the old bug reports and see what
knowledge i can reuse.)

from the patch and your warning about the defaults.dia I think I should be able
to come up with similar patches for various other objects.  

If I can get this done it offers the potential of some really nice screenshots
to go with the next release, a bit of eye candy as it were.  Also by fixing them
ALL hopefully it will prevent future developers from creating new shapes that
dont work properly with the default colours.  

Changed the summary to be more general.  

I've been reading and experimenting with the code and it occurred to me that for
things like the white arrowhead used by generalisation it should be inheriting
the foreground colour.  I'll try and fix the colourless objects first and maybe
later create a seperate bug report to deal with arrowhead fills.  

The UML case is fixed, the rest is much too broad for a useful bug report:

2008-04-20  Hans Breuer  <hans@breuer.org>

	* objects/UML/object.c : also write 'name' in text_color
	* objects/UML/association.c : line_color and text_color
	* objects/UML/component_feature.c : added line_color
	* objects/UML/fork.c : added fill_color
	* objects/UML/state_term.c : fill_color and line_color
	* objects/UML/transition.c : fill_color and text_color
	=> all UML shapes can be tinted now, closing bug #169107