Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Merging does not work for preset and user defined color palettes, bitmaps, gradients, hatches and line ends|
|Component:||chart||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|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|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
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