20180114 release

[NicoHood]

Release History

Release 20180114

• General cleanup of outdated gtk versions and extras
• Readme update
• Minor fixes for cinnamon and xfce4
• Add budgie desktop styling budgie desktop styling #16 #17
• Slightly darken fonts for light theme to improve contrast Slightly darken fonts for light theme to improve contrast #15
• Switch building from gulp to sassc
• Mate screensaver styling Mate screensaver styling #27
• Install plank theme with makefile directly

Release 20171105

• Latest master from horst3180 when this softfork was created.

Release 20170302

• Last official release by horst3180 upstream

[NicoHood]

I still get an error for a missing css file (which I deleted):

make[3]: Leaving directory '/build/arc-gtk-theme/src/arc-theme/common'
cp ./index.theme-darker /build/arc-gtk-theme/pkg/arc-gtk-theme/usr/share/themes/Arc-Darker/index.theme
/usr/bin/mkdir -p /build/arc-gtk-theme/pkg/arc-gtk-theme/usr/share/themes/Arc-Dark
cp ./index.theme-dark /build/arc-gtk-theme/pkg/arc-gtk-theme/usr/share/themes/Arc-Dark/index.theme
/usr/bin/mkdir -p /build/arc-gtk-theme/pkg/arc-gtk-theme/usr/share/themes/Arc/cinnamon
cd ./cinnamon && cp thumbnail.png /build/arc-gtk-theme/pkg/arc-gtk-theme/usr/share/themes/Arc/cinnamon
cd ./cinnamon && cp -R \
	common-assets \
	light-assets \
	cinnamon.css \
	/build/arc-gtk-theme/pkg/arc-gtk-theme/usr/share/themes/Arc/cinnamon
cp: cannot stat 'cinnamon.css': No such file or directory
make[2]: *** [Makefile:427: install-data-local] Error 1
make[2]: Leaving directory '/build/arc-gtk-theme/src/arc-theme/common'
make[1]: *** [Makefile:307: install-am] Error 2
make[1]: Leaving directory '/build/arc-gtk-theme/src/arc-theme/common'
make: *** [Makefile:345: install-recursive] Error 1

Edit: Fixed in later commits. I think we need to enable sassc for all gtk versions to work properly. Otherwise we have a mix between gulp and sassc which is really not a good idea.

[NicoHood]

We have to use sassc for all gtk versions or not at all. Otherwise we have a mix of css and scss files which is a pure mess to maintain. You introduce a new tool but have to maintain both. We are no companies, we dont want that mess ;) Especially because 18.04 of ubuntu has sassc and debian also. Older distros only have legacy releases then if they dont build with sassc.

Also PRs like your budgie and darken fonts pr give tons of unresolvable conflicts. For distributions without sassc you can install it manually:
https://askubuntu.com/questions/849057/how-to-install-libsass-on-ubuntu-16-04

[fossfreedom]

What DE is that? - need to reproduce it to have a look.

[fossfreedom]

ah - this must be XFCE - and I saw this horst3180/arc-theme#800 - that colour variation for the panel is a pre-existing issue. I guess explicitly setting the color of the xfce panel may work - something like this off the top of my head:

.xfce4-panel.panel {
   background-color: $panel_bg;
   color: white;
   ....

or maybe:

.xfce4-panel.panel {
   background-color: $panel_bg;
   color: $fg_color;
   ....

or maybe:

.xfce4-panel.panel {
   background-color: $panel_bg;
   color: $panel_fg;

....

[NicoHood]

Alright, i will have a look into this. Can you please check my todo list from the very top and give me feedback on those?

I would remove the chrome theme, add the plank theme to the makefile. Do you agree?

[fossfreedom]

Yep - agree with both suggestions - chrome and plank +1

As an aside - my debian package manually installs the plank theme- so I'm happy to remove this unnecessary hack.

[NicoHood]

Where do we need to put the code to install the plank theme? I guess inside the makefile of the extra directory? I have no idea, can you help please?

All other issues i have postponed for the next release, unless you fix them in time. But its not critical now.

Release history is still TODO.

[NicoHood]

@fossfreedom Where should we put the release notes? To the github releases directly? That is how it was done before.

Did I miss anything special?

In order to better track all new changes, we really need to only work with PRs and tag them with milestones. So no direct committing to master if possible, as I will only read PRs for the release history. Otherwise it is a real mess to write a proper release history.