Issue 81406

Summary: Merging does not work for preset and user defined color palettes, bitmaps, gradients, hatches and line ends
Product: General Reporter: cno
Component: chartAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: ace_dent, andreas.schluens, carsten.driesner, issues, Mathias_Bauer, pagalmes.lists, rb.henschel
Version: 3.3.0 or older (OOo)Keywords: oooqa
Target Milestone: ---   
Hardware: All   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 105642    

Description cno 2007-09-09 10:32:16 UTC
Using the Dutch version, build 9215.
I cannot find the new chart colors in the default pallette nor in the section
Tools|Diagrams|Default colors.

Related to issue #75202 and specs
http://specs.openoffice.org/chart/OptionsChartColors.odt
Comment 1 Regina Henschel 2007-09-09 11:07:52 UTC
In the rc2 German version they are there. How do you install? Do you use a new
user folder? Please start OOo with a new user and look whether the colors are there.

Please look into standard.soc in user/config and presets/config with an editor.
The new colors should be there at the end of the text with "Chart 1"... 
Comment 2 cno 2007-09-09 11:28:21 UTC
Hi Regina,
I install over the previous versions of OOo.

The colors are in the ...\presets\config\standard.soc
The colors are not in the ...\user\config\standard.soc

Might that be due to the fact that I've ever (2.0.x) added some colors myself
that BTW got lost when installing the next version?

BTW, see #81407 about problems with color management.

Comment 3 cno 2007-09-09 15:38:46 UTC
Started 2.3 with brand new dummy user and the new colors were there.
In my own account, copied standard.soc from ...\presets\... to ...\user\... and
pasted my custom colors  from a bak-up of the old standard.soc in the fresh
.soc-file.

Now everything is fine... apart from the fact that installing 2.3 over a
(certain kind of) existing configuration doesn't add the new colors :-(
Comment 4 kla 2007-09-10 12:42:47 UTC
@BM: we should found a general solution for this behaviour.
Comment 5 cno 2007-09-10 12:46:35 UTC
Is there an overview of affected areas: what user-settings conflict with new
config/data by installing a nex version?
  
Comment 6 bjoern.milcke 2007-09-10 12:54:17 UTC
I think all the standard.so? files are affected. That means whenever you added
your own gradient, hatch, fill bitmap or color, you won't get updates when
transferring personal data. That it because when you add one of those things,
the standard.so? file is copied from presets to your user-settings, which is
then modified there. Updates don't overwrite this file later. (Actually, only
the colors were modified yet).

What we need would be a mechanism that merges new objects into existing lists.
Which might become problematic when the name conflicts with a user-objects, but
of course not unsolvable.
Comment 7 cno 2007-09-10 14:35:59 UTC
@bm: thanks for the explanation.
For advanced users something they can cope with - when you know what's going on.
But not something to leave unchanged ;-)
Does the same aply for some of the other folders in config? Or should we ask
framework/cd?
Comment 8 cno 2007-09-10 14:38:49 UTC
Apologies. I should have typed:
Does the same apply for some of the other folders in presets? Or should we ask
framework/cd?
Comment 9 bjoern.milcke 2008-01-17 09:17:34 UTC
->cd: Do you know anything about a general "configuration merge approach"
planned for 3.0 or later? In this case we would need to merge two versions of
the XML-file standard.soc containing colors with their names.
Comment 10 carsten.driesner 2008-01-17 09:43:48 UTC
Adding mba and as on CC.

cd: Currently there is no special merging process planned for non-configuration
data (xcs/xcu based). One can think of converting the files into the
configuration based-data structure or implement a special merging services that
solve this problem.
Comment 11 Mathias_Bauer 2008-01-17 12:48:56 UTC
I strongly recommend to move all data that should be mergeable to the xcu files.
It doesn't make sense to reimplement merging again and again. In the xcu files
you get it for free (if you design your schema properly of course).
Comment 12 bjoern.milcke 2008-01-21 13:31:58 UTC
The problem here is that you can have more than one color palette. I don't know
how this fits well into the registry.

->CL: Please consider making the palettes part of the registry, or implement the
merging for *.so? XML files.
Comment 13 Mathias_Bauer 2008-01-21 14:41:58 UTC
The registry allows to put in as many color palettes as you want - provided that
you have designed your schema properly. 
Comment 14 bjoern.milcke 2008-01-21 16:51:30 UTC
Note: As for OOo 3.0 it is planned to get a new standard color palette, this
issue is important for this release. See issue 77347.
Comment 15 clippka 2008-03-12 16:27:34 UTC
I have no solution for this issue. Moving to registry may be possible but only
works for color palletes, but we also have bitmap, gradient, hatch and lineend.
At least for bitmap the registry is no solution as we need a storage to put the
bitmap data in. I'm not considering a base64 encoding as a solution.

Next problem is that we then need a feature to enable users to exchange
palettes, which is currently possible since they are single files.

Also merging is not always a good idea. When we get a new color palette we do
not want to have the the old and new colors merged. We may only want to merge
user defined colors with the new colors to not loose content the user created.
But there is currently no way in deciding what was user content and what was pre
installed content, at least not with the registry merging.

The next issue is that our current pallete handling and user interface needs a
redesign since years as it is currently not very user friendly.

So a move to registry for colors is more work than initially thought, also there
will be no new color palette for 3.0. Therefore I change this issue to Office
Later. If anyone needs this faster than he must find resources for it...
Comment 16 cno 2008-03-12 19:50:45 UTC
Hi Christian,
Thanks for your thoughts on this. I understand the problems.
One remark, just to clarify (if necessary at all, cannot read this from your
comments). There are various situations:
Those where the user expects that the custom colors are preserved.
And those where the user expects that newly introduced colors are available.

When installing a new major release (3.0) I would not be to surprised if my
custom colors are not copied from the older installation.
When installing a new minor release with new colors, I will be surprised if
those are not available.
Maybe somthing can be done with an extension to force merging of user and preset
xcs/xcu based data. Although that might cause some errors, as you explained.

Apart from this all: shouldn't we change summary to something as:
"Merging does not work for preset and user defined color palletes, bitmaps,
gradients, hatches and line ends".
Comment 17 clippka 2008-03-13 11:11:54 UTC
Hi Cor,

you are right. After some more thoughts about this maybe the registry is not
that bad idea after all. Need some thoughts about how to handle bitmaps and a
new user interface to import and export palettes. But I forget that registry
would also enable exchanging palettes as extensions. I changed target back to
3.x and give this some more thoughts.
Comment 18 cno 2008-03-13 11:29:36 UTC
Thanks Christian. 
This morning I realised a probably related issue (up to you to decide), but not
yet mentioned: merging of user defined and preset key board short cuts/accelrators.
See this thread:
http://framework.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=1768521
Comment 19 ace_dent 2009-10-07 18:04:14 UTC
To manage the many suggestions for enhancing the color palette, I have created a
meta-issue here:
Issue 105642 - Re-design and UI improvements for color palettes

The purpose of the new issue is for management only, it does not duplicate
specific design requests (that we wish to capture).

Many thanks,
Andrew
Comment 20 Marcus 2017-05-20 11:27:39 UTC
Reset assigne to the default "issues@openoffice.apache.org".