In the area-dialog on the last 4 tabpages it´s possible to define new 
colors, gradients, hatchings and bitmaps. On the tabpge "Bitmap" it´s 
also possible to import other grafics as filling.

no issue, so it is closed.

Sorry, didn't notice it...
But that only indicates that this is counter-intuitive and needs
redesign. Reopening bug, changing summary.
What needs to be accomplished, is that a user isn't forced to create a
new preset every time he needs a custom fill!

My proposal for a solution: In the area tab, add a new item at the
botton of every list (colors/gradients/hatchings/bitmaps), that would
read "Custom...".
It would open a separate dialog that would be basically the same
component that ones we see on colors/gradients/hatchings/bitmaps tabs.
It would, however be a slight variation of them. The button set
"Add...", "Modify...", "Delete..." would be replaced with single "Add
to presets...". 
Let's assume the user wants to use a custom gradient.
Three scenarios of operation would be possible in that dialog:
1. User doesn't want to create a new preset. He sets up a gradient he
needs, then clicks "OK" at the bottom.
2. User wnats to create a new preset and use it. He sets up a gradient
he needs, then clicks "Add preset..." and inputs a name (gradient gets
added to the presets), then clicks "OK" at the bottom.
3. User wants to cancel setting up the gradient and clicks "Cancel".
If he added the gradient to the list, it stays on the list.

Those changes would probably require to separate the "Add...",
"Modify...", "Delete..." button set from
color/gradient/hatching/bitmap fill editor components to achieve
flexibility we need here, but it would be worth it.

The current paradigm we use in treating fills (that requires use of
presets) is very uncomfortable an counter-intuitive. Using of presets
should be a convenient option, not inconvenient requirement.

For Product Managment.

This issue is re-assigned to Christian Jansen for further evaluation.

Aleksander, you are right it should be more inuitive.We are thinking
about an concept. Due to the fact that there are many changes
naccessary it could take a little bit longer.

Hopefully we get this changed to oo.o 2.0, otherwise we have to target
this to oo.o 3.0.

I think, that format-area is no good place to load, alter and save the soc, sog,
soh and sob-palettes at all. I propose to make a new dialog "alter palettes" and
place it into the Tools-menu so that it is available without any draw-object,
but continues being specific to each module.

Regina, 2 questions:

1) Could you argument why is this not a good place for altering the palettes (as
it seems to be the most obvious place for me...). I do agree that the palettes
editing dialog should be accessible without selecting any drawing object, but
this is not a reason to not allow accessing it from other places (the one
covered in this bug being the most obvious to the user IMO)

2) Does your proposal assume that there would still be implemented a way to use
ad-hoc settings without regard of content of palettes (I really hope that it
does, because I know from my experience that the separate config dialog would be
the last place where users would look for a solution)?

Also, keep in mind that this separate dialog launchable from a different part of
the UI would actually fragment the UI and add command buttons and menu items
with no good justification, thus complicating user experience.

This issue doesn't refer only to the drawing-module. Imaging you are in Calc and
you will define an own color for a cell-background. Now you have to draw a
rectangle, go to the format-area dialog of the rectangle, define your color,
then delete the rectangle and then you can use the new color for your cell
background. The same thing in writer: Defining a new color for font or
background can only be done by a temporary draw object. That's not intuitive. So
people think, that defining new colors is impossible, see the issues 11098,
16217 and 20105.

Another reason for a separate dialog is the fact, that the changes, which will
be made in the format-area dialog, will not only change the color of this
special draw object, but will change the available colors for all further using
of colors in that document. Such far-reaching changes should not be made in a
place, where each other thing is a hard formating of a single object.

> Imaging you are in Calc and
> you will define an own color for a cell-background. Now you have to draw a
> rectangle, go to the format-area dialog of the rectangle, define your color,
> then delete the rectangle and then you can use the new color for your cell
> background.

My proposal covers creating and modifying those directly from any dialogs/drop
downs that involve fill styles. So in this case, you wouldn't have to create a
temporary shape - you'd just select a cell to be filled, click on the
"Background Color" button on the formatting toolbar, where you'd select
"Custom..." instead of a pre-defined color. You'd get a color picker dialog,
you'd choose a color you like, and click OK. Then the cell would be filled with
a custom color, definition of which wouldn't be persisted in a global OO
registry of colors, but in the cell itself (that's what I call an ad-hoc fill
style). It wouldn't pollute any of the palettes, it would exist only in that
single cell.

> Another reason for a separate dialog is the fact, that the changes, which will
> be made in the format-area dialog, will not only change the color of this
> special draw object, but will change the available colors for all further using
> of colors in that document. Such far-reaching changes should not be made in a
> place, where each other thing is a hard formating of a single object.

That's why I advocate creating an infrastructure for ad-hoc fill styles. When a
fill style can be unique to one hard-formatted shape, there's no problem.

Maybe I should change the summary of this bug, or open a new one, since it has
become apparent that ad-hoc fill styles and easier editing of fill style
palettes are a separate thing?

Hmm, in fact, I've checked my new installation of OpenOffice 1.1 and I can see
that this particular issue (creating/modifying presets directyl from formatting
dialogs) has been resolved :)))

I can set my custom fill style (e.g. create a shape in Writer, go to
Format->Area and click-out any gradient I like), then when I try to confirm it I
get a message "The gradient was modified without saving. Modify the selected
gradient or add a new gradient." with the buttons: "Modify", "Add", "Cancel".
That's exactly what the original issue was all about.

This is much better than in older versions of OpenOffice, but there are
currently 2 more improvements that can be made:

1) Ad-hoc fill styles (that is, fill styles specific to single drawing shapes,
not linked to any presets from global palettes)

2) 2 new buttons in all fill style (color, hatching, gradient, bitmap) lists
(which are visible in drop-downs, list boxes, "Background Color" dockers etc.):
"Custom..." and "Modify presets...". The "Custom..." button would allow to use
an ad-hoc fill style, the "Modify presets..." button would send to the palette
editing dialog.

Ad 2. To clarify what I'm meaning, I'll give an example.

In Writer, let's create an ellipse. Now suppose that I want to fill it with a
blue-purplish gradient (not currently available from the gradients palette).

I want to be able to do the following:

1) Select the ellipse (currently possible)
2) Open the 1st "Area Style/Filling" drop down and change from "Color" to
"Gradient" (currently possible)
3) Open the 2nd "Area Style/Filling" drop down and choose a "Custom..." item at
its bottom (currently not possible - only the predefined gradients are available)
4) In the gradient editing dialog, configure my own ad-hoc custom gradient and
click OK (currently not possible due to the previuos one)

I also want to be able to do the following (continuing after point 2) of the
previous list):

3) Open the 2nd "Area Style/Filling" drop down and choose a "Modify presets..."
item at its bottom (currently not possible - only the predefined gradients are
available)
4) In the gradient editing dialog, configure my own gradient preset, save it to
the palette, and click OK if I want to apply it to the selected shape, or press
"Close" if I only want to create a preset, but not apply it to the selected object.


Should I open a new issue, or modify this one's summary to reflect this change?

> Maybe I should change the summary of this bug,
 
Yes, because in area-dialog creating own colors is possible, but in all other
dialogs, where you can choose colors, you can only choose a color out of the
palette which is actual in that moment.

> or open a new one, since it has
become apparent that ad-hoc fill styles and easier editing of fill style
palettes are a separate thing?

I think a new issue for palettes is necessary and I have posted one now (27722).
I think your issue is indeed another one.

OK, I've opened Issue 27724 as a follow-up. I've also added a commented in Issue
27722 (as I agree with that issue, but think it should not cause withdrawal of
already existing functionality).

according to http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7690
this issue will be set to OOoLater

It seems that this issue is covered better by the child issue:
Issue 27724 - Support ad-hoc fill styles and offer comfortable shortcuts from the UI

Marking as a duplicate. Please move votes and comments to progress the issue.

Many thanks
Andrew

*** This issue has been marked as a duplicate of 27724 ***

Closed.