Description: 1) Use the current tools to create gradients, patterns, screening and create a file that can be used to replace Mozilla themes with the appropriate dimensions for screen resolution. 2) Include a simulation of how it will look when applying with some buttons with the current icon theme. Steps to Reproduce: 1. Tools 2. Options 3. Personalize 4. Own theme Actual Results: Personas themes don't work Expected Results: The freedom of a user to create a theme for the customization of LibreOffice. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 151312 [details] Exemplary simulation for the proposal
Lovely mockup ❤
So the idea here is to switch from a predefined theme to a kind of theme editor. We would provide the area fill dialog with color, gradient, and bitmap and apply the result to the tool-/notebookbar (and ideally also the other UI controls). Sounds interesting.
Yep. Definitely interesting. In fact, I was going to do something 'similar' a few months ago, but gave up because it didn't get support. :) (Search for "Please dont introduce a new dialog" in the Design channel on telegram for the context. I guess my mockup skills wasn't enough to convey the idea.) Anyway, nice & well-thought mock-up IMO.
Muhammet, please provide some code pointers to make this an easyhack.
Created attachment 151457 [details] Illustration of bad persona image rendering I think this is will be a big improvement over what we have now. Since there is no metabug for Themes/Personas, my input here is made in the hope that if this is picked up by a dev a further correction can be included in the hack. A theme requires only 2 images: header.png 3.000 x 200 & footer.png 3.000 x 100 Plus an optional preview..png 680 x 100 In the past it was possible to "tweak" your own persona, by creating a suitable header.png (footer.png & preview.png were optional) in <user profile> user > gallery > personas > my_persona and editing a couple of lines in the "Expert Configuration". This method no longer works, although "substituting" your own PNG's for one of the themes in the <install directory> share > gallery > personas almost works. "Almost", because somewhere between the LO 5.x & 6.x series the code was changed and instead of a nice smooth background across both the menubar and main toolbar, the header image is separately added as the background to these bars (see attachment). I suspect this is the reason why only plain color PNG's have been included with the (dark, gay, green, pink, sand & white) personas supplied with the installation package. Unless the method of rendering the persona/theme images is reverted to that used in the 5.x series, Leandro's proposed options for images with other than plain colors might create some undesirable results. Pattern & Hatch might work, gradient might appear strange, but bitmap will have the same impact as shown in the attached Bad_Persona_Rendering.png
(In reply to Dave Barton from comment #6) > I think this is will be a big improvement over what we have now. Since there > is no metabug for Themes/Personas, my input here is made in the hope that if > this is picked up by a dev a further correction can be included in the hack. There is this meta: bug 86544
(In reply to Dave Barton from comment #6) > ... > A theme requires only 2 images: Not necessarily when we go with our own dialog. The bitmap could be stretched, filled, patterned... or you just paint a gradient (which is likely the most common type).
(In reply to Buovjaga from comment #7) > (In reply to Dave Barton from comment #6) > > I think this is will be a big improvement over what we have now. Since there > > is no metabug for Themes/Personas, my input here is made in the hope that if > > this is picked up by a dev a further correction can be included in the hack. > > There is this meta: bug 86544 Not exactly the best metabug ever created. It did not reference this bug, but does now.
(In reply to Heiko Tietze from comment #8) > (In reply to Dave Barton from comment #6) > > ... > > A theme requires only 2 images: > > Not necessarily when we go with our own dialog. The bitmap could be > stretched, filled, patterned... or you just paint a gradient (which is > likely the most common type). What you are describing is what might be the case "when we go with our own dialog", what I was describing has been the case up until now.
*** Bug 125448 has been marked as a duplicate of this bug. ***
(In reply to Leandro Martín Drudi from comment #1) > Created attachment 151312 [details] > Exemplary simulation for the proposal Thank you for the mockup. Is there an English version of it?
(In reply to Muhammet Kara from comment #12) > (In reply to Leandro Martín Drudi from comment #1) > > Created attachment 151312 [details] > > Exemplary simulation for the proposal > > Thank you for the mockup. Is there an English version of it? Just take the area fill dialog as example (with a specialized preview ideally but not necessarily). The original idea is discussed here https://design.blog.documentfoundation.org/2015/12/22/area-fill-options-made-consistent/
Rania, you might be interested in this topic.
It look like what LOTC did, but i still not sure.
*** Bug 147954 has been marked as a duplicate of this bug. ***
*** Bug 137414 has been marked as a duplicate of this bug. ***
I don't understand what this bug is about: 1. LO is a FOSS project; why do we need proprietary tools? 2. What Mozilla themes? We use Mozilla themes? Perhaps you mean Mozilla-like theming? 3. "reuse the existing" - existing what? themes? dialog?
(In reply to Eyal Rozenberg from comment #18) > I don't understand what this bug is about: > > 1. LO is a FOSS project; why do we need proprietary tools? > 2. What Mozilla themes? We use Mozilla themes? Perhaps you mean Mozilla-like > theming? > 3. "reuse the existing" - existing what? themes? dialog? Do you really think that your comment contributes something to the issue? A constructive opinion can be useful, but a comment where only by technicalities you reject something that has been perfectly clarified does not contribute anything and obstructs an effective communication. The report has been here for years because it was proposed to use LibO tools to make themes to replace Mozilla Themes as they were used until a few years ago. If you want more information, read the previous posts and comment something constructive.
I believe it would be wise to retitle this ticket to replace "proprietary" by "in-house" or "custom"; I can guess this is certainly the meaning that was intended by Leandro. Proprietary can either mean "not common" (especially for latin-based languages) or refer to proprietary _licensing_, but in the FLOSS world most people are not used to interpreting this term with the former meaning, and immediately think of the latter meaning. Avoid this term if you don't want angry mobs coming at you over a misunderstanding.
Honestly, I don't speak English. I just used Google to translate. I will now take advantage of Artificial Intelligences to make the translated texts clearer. But I believe that if it leads to misunderstandings, it should be changed. The intention refers to reusing what has already been created and "adapting" it to create themes.
*** Bug 162394 has been marked as a duplicate of this bug. ***
Sahil, resolved as fixed?
https://wiki.documentfoundation.org/ReleaseNotes/25.2#Application_Theming LibreOffice now has it's own theming system. It provides color customization options for almost all the UI elements and bitmap customization for the app background. Further improvements would be based on user input (on different tickets of-course). Marking as resolved :).