After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 93933 - Colour Fill fails for custom objects
Colour Fill fails for custom objects
Status: RESOLVED INCOMPLETE
Product: dia
Classification: Other
Component: general
0.90
Other Windows
: Normal minor
: ---
Assigned To: Dia maintainers
Dia maintainers
: 95524 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-09-23 03:42 UTC by aisaac
Modified: 2011-06-05 12:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description aisaac 2002-09-23 03:42:37 UTC
Changing the fill color fails for custom objects.
To see this, place a 
Logic/Crossconnector object 
on a Dia canvas, double-click it, and change the
fill 
color in the dialogue that opens.  The color
change does not show up on the canvas.
Comment 1 Steffen Macke 2003-01-04 11:26:01 UTC
Changing the following lines in
connector.shape

<svg:ellipse style="fill: #020202" cx="9.25" cy="4.25" rx="0.25"
ry="0.25"/>
    <svg:ellipse style="stroke-width: 0.1; stroke: #000000" cx="9.25"
cy="4.25" rx="0.25" ry="0.25"/>

into

<svg:ellipse style="fill: background" cx="9.25" cy="4.25" rx="0.25"
ry="0.25"/>
    <svg:ellipse style="stroke-width: 0.1; stroke: foreground"
cx="9.25" cy="4.25" rx="0.25" ry="0.25"/>

solves the problem. There are many custom shapes which are not using
the "foreground" and "background" colors properly.
Comment 2 Alan Horkan 2003-02-11 01:00:10 UTC
What Dia really shoudl be doing is changing all 
style="fill:
to match new background value the user specifies
and similarly overriding the stroke style.  

Addmittedly this is crude but this is the behaviour Visio uses and is
reasonable.  Editing all the shapes to include foreground and
background variables would be very time consuming, and unfortunately i
am not yet good enough at shell scripting to automate it.  

We could probably use foreground and background where available and
otherwise just override the style of fill and stroke and get the best
of both worlds.  


Comment 3 Alan Horkan 2003-11-28 19:40:54 UTC
*** Bug 95524 has been marked as a duplicate of this bug. ***
Comment 4 Alan Horkan 2003-11-28 19:45:12 UTC
Closed bug and copied over Comments from Bug 95524. 
I dont think the problem needs to be fixed in the shape exporter
despite what I seemed to think at the previous time of writing.  

-- 


currently if the .shape file has color set to anything other than None
then users are not allowed to change the shape color when they use it.

As a result most of the templates have to be in boring black and white.  
If i were to set a shape as Red then it would have to stay red, and Dia
would not allow the user to change it.  

Hopefully i have explained this clearly enough.  

Need to dig up my previous posts about this from the archive.

------- Additional Comments From Alan 2002-10-11 15:28 -------

discussion from the mailing list.  

Answer [Re: cannot change shape fill color]
http://mail.gnome.org/archives/dia-list/2002-June/msg00414.html
  start of thread, but the above link is the most relevant one.  
  http://mail.gnome.org/archives/dia-list/2002-June/msg00403.html

a response from Steffen:
> You find the shape export code under plug-ins/shape.

------- Additional Comments From Alan 2003-01-19 21:12 -------

I have thought about this further and looked at how visio behaves.  

what visio does to a shape like this
  / \
 /   \
|\   /|
| \ / |
|  |  |
\  |  /
 \ | /
  \|/
that has a diffferent colour on each side

is changes them all to be whatever new fill colour you assign.
Although it is not ideal it is better than nothing.    

This behaviour seem to me a lot like assuming that the new foreground
colour applies to all the 
style="fill: #??????"
and the new background colour applies to all the 
stroke: #??????"

Hopefully my attempt at describing this will be of use when some one
tries to implement this.  

------- 
Comment 5 Lars Clausen 2005-03-05 11:52:55 UTC
The really good way to fix this would be to have options during export asking whether to stick 
with the given colors or not.  For some shapes, the colors have meaning, for most shapes, they 
should be determinable by the user.

In the meanwhile, going through the old shapes and fixing them where reasonable would be a 
nice, simple task.
Comment 6 Lars Clausen 2007-09-23 18:20:17 UTC
Marking as bug rather than enhancement since a number of the current shapes are, in fact, broken in this respect.
Comment 7 Torge Husfeldt 2008-06-10 12:42:15 UTC
I've done a rough count in order to find the places that need fixing and came up with:
- Total occurences of the exact string style="fill: in shapes:
1945
- in different files:
398
- with the following by occurrences for each value:
occurences value      ToDo
        10 #cccccc    ?
        10 inverse    check if valid - if so leave alone
        11 #7a7a5a    ?
        12 #ff0000    ?
        13 #cdcdcd    ?
        14 #c9c9b6    ?
        16 #bfbfbf    ?
        18 #c0c0c0    ?
        21 #0000ff    ?
        22 #00b4ff    ?
        22 #d9d9cd    ?
        24 #005a80    ?
        26 bg         check if valid - if so leave alone else replace with "backgound"
        28 #b7b796    ?
        38 #ffffff    most probably replace with "background"
        48 #0096d4
        92 #000000    most probably replace with "foreground"
       181 foreground leave alone
       258 0          check 
       264 none       check if valid - if so leave alone
       295 default    leave alone
       347 background leave alone
Can anyone comment on these ToDos?
Comment 8 Hans Breuer 2009-01-09 23:50:30 UTC
It is perfectly fine for shape to include unchangeable colors - most of the Cisco shapes are a good example. I'm afraid the task can not be solved without looking at each of the shape files in question.
Comment 9 ipatrol6010 2011-02-11 03:58:49 UTC
AAMoF, this is how I encountered this glitch. Cisco icons are not meant to be transparent. Can someone please fix this in a sane manner?
Comment 10 Hans Breuer 2011-06-05 12:08:38 UTC
(In reply to comment #9)
> AAMoF, this is how I encountered this glitch. Cisco icons are not meant to be
> transparent. Can someone please fix this in a sane manner?
Sorry, I don't even umnderstand the comment neither can I relate it to the discussion above. Also I like to get a more specific description as comment #5