[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2023-03-31 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #14 from Regina Henschel  ---
(In reply to Heiko Tietze from comment #9)
> Wonder if this theme color  brightness control would be
> disabled in case of a RGB color or hidden.

Setting brightness is also available for non-theme colors in gradients in MS
Office. And this information is written to file. We too have already
"intensity" for colors in gradients, which is actually reducing luminance and
written to file. So at least for colors in gradients we need a brightness
control for all kind of colors.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2023-03-31 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #13 from Regina Henschel  ---
Created attachment 186369
  --> https://bugs.documentfoundation.org/attachment.cgi?id=186369=edit
Theme color customize dialog in MS Office

(In reply to Heiko Tietze from comment #10)
> Another question is how we handle (hyper) link colors since we take it
> currently from the system (and allow customization per app color). I omitted
> the two colors in my mockups.

MS Office do not show 'hyperlink' and 'followedHyperlink' when the user selects
a color for shapes, text, borders, ...
But they are included in the dialog to customize theme colors, see attachment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2023-03-31 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #12 from Heiko Tietze  ---
(In reply to V Stuart Foote from comment #11)
> That link gives an oops, but the link from comment 6 seems to work. Has the
> revised mockup?

My bad, should copy the official link. And yes, it's the same mockup but with a
second page (landing page is new). Find arrows at the left/right side to switch
forward/backward.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2023-03-31 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #11 from V Stuart Foote  ---
(In reply to Heiko Tietze from comment #9)
> 
> Amended my mockup at
> https://design.penpot.app/#/view/d9665a57-0073-80a2-8002-47af3e11cf33?page-
> id=d9665a57-0073-80a2-8002-47af3e11cf34=interactions=0 

That link gives an oops, but the link from comment 6 seems to work. Has the
revised mockup?

https://design.penpot.app/#/view/d9665a57-0073-80a2-8002-47af3e11cf33?page-id=d9665a57-0073-80a2-8002-47af3e11cf34=interactions=0=d5fc0283-ef1c-80fa-8002-47d90c42f7c6

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2023-03-31 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #10 from Heiko Tietze  ---
Another question is how we handle (hyper) link colors since we take it
currently from the system (and allow customization per app color). I omitted
the two colors in my mockups.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2023-03-31 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #9 from Heiko Tietze  ---
(In reply to Regina Henschel from comment #8)
> Created attachment 186332 [details]
> Solid fill and gradient fill

Amended my mockup at
https://design.penpot.app/#/view/d9665a57-0073-80a2-8002-47af3e11cf33?page-id=d9665a57-0073-80a2-8002-47af3e11cf34=interactions=0
with this idea (the preview has now two pages, see arrows left/right).

I don't think we need the extensions link in the picker on the theme color.
Replaced it by access to the "edit theme color" dialog shown in the mockup too.
I suggest to not "bleed" the UI into the left column and adjusted the
positioning a bit. Wonder if this theme color  brightness control would be
disabled in case of a RGB color or hidden.

With this UI it might be a challenge to spot whether a themed color is chosen
or something from the RGB palette.

The theme color editor should be self-explanatory.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2023-03-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #8 from Regina Henschel  ---
Created attachment 186332
  --> https://bugs.documentfoundation.org/attachment.cgi?id=186332=edit
Solid fill and gradient fill

Theme colors (MS Office "schemeClr") are different from palettes because the
set of scheme colors is stored in the file and bound to the master page. As
Writer has only one master page it can only have one set of scheme colors.
Impress/Draw can have several master pages and thus several sets of scheme
colors.

If you want to change a theme, that means effectively a change of the master
page. So I agree with V Stuart Foote that changing or editing the set of scheme
colors should not be in the area dialog but could be located in the master page
dialog in Impress. In Writer it cannot be inside the page style dialog, because
there is only one set of scheme colors. [Perhaps a new dialog with all document
wide settings in Writer?]

For selecting a scheme color, I prefer to have it separated from the palettes.
There could be a dedicated area for it, see my attachment.

Lighten/darken can be a new control, consisting of a set of buttons with
stepped examples and a field for numerically determine the value. MS Office
allows light and darken not only for scheme colors but for all colors.
Therefore I would allow lighten/darken for palette colors too. See my
attachment.

MS Office has no fixed steps of lighten/darken but depends the steps on the
brightness of the base color. So should we do (bug 153361). It is useless to
make a light background color 4 steps lighter, or a dark text color even
darker.

The previews of the selected colors would then need to be split in showing the
base color and the selected lighten/darken variant. That is not included in my
attachment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2023-03-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #7 from V Stuart Foote  ---
I really want to keep the Theme "style" editor separate from our functional
Palette based color picker. OK to use the Theme palette from the picker as now.
But keeping two distinct dialogs please--not option #2

Yes to providing the 'Standard' colors (standard.soc) for use with the Theme
Colors... picker would be useful.  And with the 'Standard' palette the drop
list would obviously be the defined "tints" and "shades" of the standard.soc.

+1 for option #3

A good start but would we stop there? 

For Themed colors "style" dialog--how do you make changes to the Theme?
Remember the theme structure is 2-backgrounds, 2 text/foregrounds, 6 accents,
hyperlink, followed-hyperlink. And the rest of the "Theme" columns are
calculated values against those base colors: 80%, 60%, 40% lighter and 25%, 50%
darker. 

They are fixed as recorded to the palette.  Currently, you can change one
value--but you can not pick one base color to modify and recalculate its
derived values to edit the "Theme". Seems that is going to be needed.

Also, should there be some cross over by including the "active" palette from
the color picker for editing the base colors?  Maybe just link the picker as a
split button (show active color - or open picker) like done on normal toolbars?
Another reason to keep two dialogs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2023-03-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

Heiko Tietze  changed:

   What|Removed |Added

   Keywords||needsUXEval
 CC||libreoffice-ux-advise@lists
   ||.freedesktop.org

--- Comment #6 from Heiko Tietze  ---
The mockup at
https://design.penpot.app/#/view/d9665a57-0073-80a2-8002-47af3e11cf33?page-id=d9665a57-0073-80a2-8002-47af3e11cf34=interactions=0=d5fc0283-ef1c-80fa-8002-47d90c42f7c6
starts on 1) with the current implementation. While LibreOffice (on the left)
offers RGB access to set all millions of colors the theme (as implemented by
MSO on the right) is kind of a style and changing „Accent 1“ affects all places
it is used.

The requirements are:
a) pick a themed colorize
1. access different brightness/colorization steps
2. show the active theme color on the selection
3. allow special colors such as „Automatic“ (eg. for font color) and
„No Fill“ (Shapes)
b) pick a standard color
1. provide access to the recently used colors
2. allow to switch the way RGB colors are presented (eg. Palette 
filtered for HTML)
c) use the themed and standard colors on gradients and other places too
d) allow to switch the color theme to adjust to whole document appearance
(eg. from “Rainbow” to “Beach”)
e) edit and share color theme
f) edit and share standard colors and palettes

No doubt that MSO solves a) in a perfect way, and we could do the same giving
full access to the standard colors b) in an extra dialog. But we aim to give
freedom to the users and should not just copy a solution but make it more
flexible.

Option 2) in the mockup merges a) and b) into one picker. The standard palette
is reduced to save space but that’s not necessary. In contrast to the prototype
from MSO we could just present the basic theme colors denying a1 (access to the
brightness level could be given in the color dialog underneath the current
color per slider / num stepper). It adds a dropdown to pick a theme and the
load more from the extension site. Drawback of this solution is that picking a
theme when coloring a random object affect every color. Changing the color
theme might be better suited at some special place, in case of MSO at the
Design tab. We could do this in a special dialog or in the page style dialog
(respectively Slide Properties for Impress) since the setting belongs to the
whole document. 

Option 3) takes into account that the layout of 2) feels a bit crowded. It
reduces the Theme Colors to just the colors with access to the brightness
levels via dropdown menu. And while we can do this for the themed colors the
same is possible for the standard colors, as shown right hand. Changing the RGB
palette could be done in any Area Fill dialog.

Themed colors are well suited for less colorful documents as done in Writer but
less optimal when color is prime, ie. in Draw. We probably need two different
approaches.

Comments are welcome.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2022-11-24 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

Heiko Tietze  changed:

   What|Removed |Added

 CC|libreoffice-ux-advise@lists |
   |.freedesktop.org|
   Keywords|needsUXEval |

--- Comment #4 from Heiko Tietze  ---
Removing needsUXEval since input has been given but cannot set my own ticket to
NEW.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2022-11-08 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

Heiko Tietze  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=15
   ||1902

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2022-11-08 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

Heiko Tietze  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=15
   ||1900

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2022-10-14 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #3 from Miklos Vajna  ---
> If we extend ODF with a fixed set of color labels (assume that is going to be 
> needed) then I guess the "Theme" can be embedded into the documents--and we'd 
> want to handle it consistent to OOXML's encoding (if any) for better 
> interoperability.

This is already happening, we write the themed colors (those 12 ones) of a PPTX
master page into ODP & read it back, see
https://vmiklos.hu/blog/sd-theme-shape-text.html and
https://vmiklos.hu/blog/sd-theme-shape-fill.html.

I hope to work on this more in the future to use themed colors at more places
in Impress (and also Writer/Calc), once I get time to do so. :-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2022-10-13 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

--- Comment #2 from V Stuart Foote  ---
This J. Korchok blog has some good details on limits of OOXML color themes,
whose 10 color limits originates from MS Office PowerPoint color picker GUI
limitations:

https://www.brandwares.com/bestpractices/2018/02/great-color-themes/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-ux-advise] [Bug 151507] Themed color palette

2022-10-13 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=151507

V Stuart Foote  changed:

   What|Removed |Added

 Blocks||107380

--- Comment #1 from V Stuart Foote  ---
I've no great objection, so long as the current Standard color theme remains
the base cross module.  

Minor concern with using sets of "Named" color themes (of 12 fixed colors-DK1,
LT1, DK2, LT2, ACCENT1, ACCENT2, ACCENT3, ACCENT4, ACCENT5, ACCENT6, HLINK,
FOLHLINK) is the general lack of applied color theory for the themes--no logic
or functional design in the sets of color that get chosen to go into a
theme--either what we'd provide as new "Named" color themes, or what gets
passed in and mapped from os/DE.

Current Standard, Tonal and freecolour-hlc palettes are formula generated color
sets--reproducible and suitable in any part of the UI.

Overall not too much of an issue as all colors are either HEX RGB, or decimal
equivs of the RGB. And get recorded to ODF as hex RGB.  

If we extend ODF with a fixed set of color labels (assume that is going to be
needed) then I guess the "Theme" can be embedded into the documents--and we'd
want to handle it consistent to OOXML's encoding (if any) for better
interoperability.


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=107380
[Bug 107380] [META] Document colors palette issues
-- 
You are receiving this mail because:
You are on the CC list for the bug.