Numix-Frost
Numix-Frost copied to clipboard
[3.6.6] Issues related by moving cinnamon theme into numix frost repo
Since moving cinnamon theme into numix-frost-repo (under v3.6.6), there are some issues with the cinnamon theme. By now I notice the following issues:
- panel tooltip has full transparent bg (expected: opaque dark)
- OSD panel has full transparent bg (expected: opaque dark)
- desktop panel has semitransparent dark bg (expected: opaque dark)
- (main)menu and calendar applet with black fonts on dark bg (expected: a light font)
- (main)menu controls missing its themes (e.g. scroll-bar, search-box)
- no space between popup-item-icon and popup-item-text
- applet/popup-item font size increased
@lots0logs I will help you to fix these issues. Please reply to me, if you intended some of these chances will be a permanent replacement. Or if there is something else I should know. By now I will use v3.6.5 as reference.
Edit 18.11.16: additional issues:
- no selection-, hoover-highlighting in desktop panels
- no selection-, hoover-highlighting in Alt-Tab-menu
@jeweloper I had not planned on releasing the cinnamon theme changes until it was actually ready but there was a packaging issue that came up which forced my hand (an update to a core package in Arch broke cinnamon for antergos users) so I had to do the release.
I think I mentioned my plans already in one of your other PRs? Maybe not, I am not sure. Anyway, I want to replace the usages of svg images by pure CSS where possible. However, considering that there are items which are broken at the moment I guess its a good idea to fix those (with the svgs) so that they work until we have time to actually write CSS to replace the svgs.
@lots0logs Yes, that you want to replace svg by pure css you mentioned already. One specific question: In ⋜3.6.5 the main bg-color was hard coded with opaque dark (html 444). What becomes the new bg-color replacement for window-titlebar, OSD, tooltip, etc? $panel_bg_color, $menu_bg_color, $dark_bg_color or something else. Thx!
@jeweloper Check _global.scss (all colors are defined there). I know I deviated a bit from them with the panel though :sweat_smile:
@lots0logs By now, I have had only time to look at _calendar.scss. And there are some issues I couldn't fix. But maybe you've got some answers for me.
- In the first step I've tried to replace the arrow-images by pure css, but I had no success. Secondly I've I created I resource-file with all the required images, but also without success. (Is it even possible to reference to a gresource file within cinnamon.css or is it only a gtk feature?) So, is it ok, if I continue to reference all required images to the sub-directories "widget-assets", "panel-assets", etc.?
- Some colors in the compiled cinnamon.css are set with the non compiled sass-function mix(). Is it because of the wrong format of the percent parameter (percent value instead of ratio) in _global.scss? For example:
mix(#eee,#444,20%)
Thx, for your answers.
@jeweloper I reworked the assets so now all of cinnamons assets will be accessible from within the generated css file at this path: ../assets/cinnamon/some-asset-file.svg
For things that cannot be easily accomplished in CSS we can continue using the svg assets. The main thing is to get rid of any backgrounds and border images that use svgs.
I'm not sure about the reasoning behind how mix is implemented in _funcions.scss. I'll have to look into it. What exactly is the issue, I mean is something not correct in the generated CSS?
@lots0logs I've no skills in css nor in sass, but I think the mix-function should compiled into a pure hex-value. Right? It seems this is not the case.
e.g. the color of calendar-other-month-day is defined by $osd_insensitive_fg_color: mix($osd_fg, $osd_base, .6)
. And it is "only" compiled to mix(#eee,#444,0.6);
. I supposed it is because the percentage is specified by its ratio and not by its percent value (followed by percent symbol) like the doc said.
In short: $osd_insensitive_fg_color: mix($osd_fg, $osd_base, 60%)
should compiled to a hex-value. But maybe I'm wrong and ratio is also a valid format and there is another reason that it is not fully compiled.
@jeweloper I think that the intention is to let GTK mix the colors. I don't know why that decision was made but I will try to find out. Though now that I've typed that it occurs to me that Cinnamon probably doesn't offer the full set of color functions that are available in GTK themes :doh: I'll come up with a work-around asap.
@lots0logs Thx for your effort.
Today I've tried to fix u.a. the .menu/.popup-menu and the WindowList. But here I'm in conflict with your last commits.
In opposite to your .menu/.popup-menu redesign I used the current gtk3 context menu as my sample. (Which basically corresponds with the known v3.6.5. design.):
- only a light shadow and light roundness
- small item spacing
- no right/left border, small top/bottom border What are your plans? Should I first adapt your design pattern, before I open my pull request? Or is your redesign only a kind of a concept? In either case I will integrate your darken separator-menu-item and sub-menu. This looks pretty cool.
I think your changes in WindowList attempts to fix the issue with these truncated tooltips. Right? But I think this has to be fixed in the applet itself. There is already an open issue, so I think this will be fixed very soon. So that's why my pull request will revoke your changes.
@jeweloper While I'm still not 100% happy with the popup-menus, I do consider them to be good enough for now. I don't want them to look exactly like the GTK menus because the desktop shell should be easily distinguishable from GTK (IMO). I have not had a chance to get to the menu applet, but it is next on my todo list. Ultimately the goal is to have a style that blends well and feels consistent with the GTK theme (but not necessarily identical to it in all areas). Does that make sense?
@lots0logs Yes, I think so.
Personally I would favor a design that's consistent in its shell, gtk3 and gtk2 design.
Maybe it is possible to switch between the old and new style only by editing the configuration file (_global.scss).
I think if you go on and expand the // widget styles
params this could be possible.
With these expansion you could also switch easily to the new style later on, when the changes also implemented in gtk3 and gtk2 theme and everything is consistence.
And it should also be possible to easily compile a special Theme - optimized for e.g. touch displays (large space between menu items, etc.).
(And yes, guys like me can easily compile there own version with the old look and feel. :stuck_out_tongue_winking_eye:)
But I don't know if it's worth the trouble. If you like, I can have a look.
@lots0logs A administrative question: Is it helpful if I already open a pull request, even if I'm still in progress? Or is it well if I open a separate issue (e.g. "fixing calendar applet") and link it with a finalized pull request? Thx.
Personally I would favor a design that's consistent in its shell, gtk3 and gtk2 design.
Yes, of course. I agree. Though consistency doesn't always mean identical. For example, looking at the popup menus compared to the one's in GTK..there isnt very much difference:
Is it the background color that you don't like?
Is it helpful if I already open a pull request, even if I'm still in progress?
Sure. You can just note that its a WIP and once its complete you can ping me.
Looks perfect! Sorry, I think I referred to an outdated version or a faulty and inconsistent self compiled version :confused:. Forget what I wrote. It's time to immediately tidy up my project files. :see_no_evil:
I don't know if this will help, but there are some numix desktop theme variations online that still look ok.
The "numix cinnamon transparent" one appears to be completely unaltered. Maybe you can reverse engineer it to fix numix-frost. :)
While it's being solved, why not changing cinnamon default desktop theme setting from Numix-Frost to Numix-SX-Dark (not installed by default right now, but seems flawless) ?
Fresh installs would look better until it is solved :)
Simplier : set it to "Linux-Mint", which is installed by default. That's antergos-cinnamon-setup package, and /usr/share/glib-2.0/schemas/90_antergos_cinnamon.gschema.override should read (line : 18 and 19)
[org.cinnamon.theme]
name='Linux-Mint'
instead of
[org.cinnamon.theme]
name='Numix-Frost'
Who can do that ?