I'd like to rework the galleries.
First I'd like to remove the existing galleries cause they are images and can't be edited by the user.
Remove all existing galleries:
- Arrows (BUG 131786)
- Computer (BUG 131308)
- Diagrams (BUG 131787)
- Environment (BUG 131789)
- Finance (BUG 131790)
- People (BUG 131792)
- School & University (BUG 131793)
- Symbols (BUG 131796)
- Text Shapes (BUG 131782)
- Transportation (BUG 131780)
Add new symbol shape galleries:
- Arrows (BUG 131784)
- BPMN (BUG 99675)
- Network (BUG 131308)
- Sounds (no change)
- Symbols (BUG 131795)
- Flowchart (BUG 99674)
No principal objection against moving galleries to one or more extensions.
* However I don't have idea what the result would be. An empty gallery tab in the sidebar?
* And will there be a reference in the gallery to the extension page. Something like 'for more gallery items click here'
There will be < 10 complete new gallery themes. Some are already listed in c1. But the difference between the existing/old one and the new one will be that the user can edit the symbols, the shape, the color, the shadow, ...
This will be something like an todo bug which new galleries should be added.
I would have no objection if the set of extensions where still bundled, and new categories could be deselected/selected as optional components during custom install.
But object to a move to the off project 'extensions' page which would pull gallery support out of core, better that artwork is maintained as SVG on project.
Related, I'd think similar handling could be applied to collection of deployed fonts.
There is a gsoc project for better extension integration. So hope is there.
However Heiko said less than 10 galleries and that is fine I think.
I will add two galleries one for Icons (small size) and one for Symbols (large size). The idea is to have something like emojis and stickers. In this two galleries there will be different shapes (input in the subbugs welche).
In Symbols and Icons there can be a lot of different shapes in there, cause than we don't need for each shape group an separate gallery (gallery number < 10). The difference between the two will be the size (details).
Add new symbol shape galleries:
- Symbols (BUG 131795)
- Icons (BUG 131860)
(In reply to andreas_k from comment #7)
> ... something like emojis and stickers.
Emojis come with the Emoji-Toolbar (experimental yet). Just to mention, the two galleries make sense.
(In reply to Heiko Tietze from comment #8)
> Emojis come with the Emoji-Toolbar (experimental yet).
That was a metaphor.
(In reply to andreas_k from comment #9)
> (In reply to Heiko Tietze from comment #8)
> > Emojis come with the Emoji-Toolbar (experimental yet).
> That was a metaphor.
Well in truth, emoji coming from a font, eg. EmojiOne Color, Segoe Emoji, even Symbola or Noto can not be rendered to document canvas as color for now -- neither with the projects cross platform Emoji.json based Emoji widget (bug 100100) -- which remains experimental bcz of bug 105689 -- nor with os/DE provided symbol pickers.
We can place emoji's with the Special Character dialog, with the broken Emoji toolbar button, and with the os/DE provided symbol pickers, but they are not in color as VCL can not resolve color in fonts. Rendering fonts to canvas requires new dev work as in bug 104403, bug 105488, and possibly bug 121327
Meaning that if we want color Emoji's we have to provide them (likely just some subset) as graphics (SVG, not ODG/SVM) in the new "icon" or "symbol" gallery.
Now it might be appropriate to pick a selection from the CC-BY license SVG for FontAwsome (bug 127983), leaving Emoji One and Symbola for the Special Character dialog.
For naming the gallery entries, I'd incorporate either the UNICODE glyph names, or better just the numeric codepoint for each glyph actually used.
(In reply to V Stuart Foote from comment #10)
> We can place emoji's with ...
Oh, and forgot to include the keyboard based method, of AutoCorrect replacement table insertion, e.g. :<emoji>:, but no color glyphs there either.
Maybe that limited subset of symbol glyphs would be the right scope to add to Gallery in color (available by locale's .PO file).
The AutoCorrect's emoji replacements are in the DocumentList.xml adjusted for each locale
Everything that is available in an font should be available by the font and not by an gallery. Fonts are the best option to have. Gallery is for shapes and not for font stuff. And Emojis are available via font.
(In reply to andreas_k from comment #13)
> Everything that is available in an font should be available by the font and
> not by an gallery. Fonts are the best option to have. Gallery is for shapes
> and not for font stuff. And Emojis are available via font.
Except that they are not rendered as text glyphs in *color* (other than forground color being set), and can't be until support is provided for color fonts as in the bugs referenced.
Meanwhile some subset of the Emoji landscape could appropriately be provided via Gallery in full SVG colors.
(In reply to V Stuart Foote from comment #14)
> Meanwhile some subset of the Emoji landscape could appropriately be provided
> via Gallery in full SVG colors.
Thanks for the feedback, than you will get an emoji gallery ;-)
(In reply to andreas_k from comment #15)
> ... than you will get an emoji gallery ;-)
Not installed by default, please. A few smileys among the symbols sounds okay to me but not a full replication of the emojis.
Discussion about an Emoji gallery BUG 131913. Will be available via extensions.libreoffice.org
Created attachment 159828 [details]
Green folder color in elementary
(In reply to Rizal Muttaqin from comment #18)
> Created attachment 159828 [details]
> Green folder color in elementary
Just a trivial question: Why new gallery color use green instead of default blue. As far as I know, the green folder indicates that the gallery items came from extension (Breeze, Colibre and elementary use different colors for gallery folder while Karasa Jaga, Sifr and Tango use same colors)
The color show if the gallery is located in the system dir or the user dir. So if you can edit the gallery or not.
All galleries should be located in the user dir cause than the user can edit and extend them.
A side effect of this rework is that now the gallery theme names (Arrows, Computers, Diagrams, etc.) are no longer localized, except for Sounds which stayed in the system directory.
Previously they were localized through .str files like $INSTALL_DIR/share/gallery/sounds.str, there are currently no .str files in $PROFILE_DIR/4/user/gallery/ directory.
Should I open a separate bug for this issue?
(In reply to Ming Hua from comment #21)
> Should I open a separate bug for this issue?
Please do so.