Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Sass-Port needs testing #50

Closed
horst3180 opened this Issue Jan 24, 2015 · 26 comments

Comments

Projects
None yet
2 participants
Owner

horst3180 commented Jan 24, 2015

Hi,
I uploaded two new branches: sass-port and sass-port-3.16
As the name says it is a port of the newest version (Gtk 3.10 and 3.12 versions remain unchanged) of the theme to Sass, a CSS preprocessor.
The goal behind this was to make the theme easier to maintain and be closer to Adwaita.

I tried to keep the appearance as close as possible to the original theme, however there are some minor changes. The biggest one is, that normal toolbars (see Abiword) are no longer dark, this fixes some annoying bugs and makes life easier for me. Note that primary-toolbars (see Rhythmbox) remain the same.
With that in mind, there is also a ton of bugfixes, and a nicer overall codebase.

Because this is a major change, I may have accidentally introduced some regressions. This is why I need people to test the theme thoroughly and report the issues they found here.

What needs testing?

  • Generally every Gtk 3.14 application you can find, especially non-gnome apps like Nemo or Granite apps
  • Ubuntu 15.04 with Gtk 3.14 and Unity
  • Elementary Os Freya with the new Gtk 3.14 update (things are not finished in the theme, but bug reports would be very helpful)
  • If you have some unstable Gnome 3.15 apps installed via JHBuild, test them with the sass-port-3.16 branch

Make sure you test with all variants (default, light, dark)

Thanks in advance for everyone willing to help :)

Edit: I pushed the sass-port branch to master and the sass-port-3.16 branch to wip/3.16. All major bugs should be ironed out now and I consider the sass port stable.
Everything of the above is still true, the branches just changed.

Contributor

vltr commented Jan 26, 2015

Hey @horst3180 ! This is great news. But, sorry if this question may sound awkward, but why did you choose Sass (AFAIK needs Ruby) rather than Less (which can be run from Java (Rhino) or Node) ? I ask this because Ruby, even using renv or something like that is a PITA (IMHO), while Node + Grunt allow us to create vanilla JavaScript build scripts, while Less is quite more "logical" and closer to CSS?

Best regards,
Richard.

PS: This is just my humble opinion or, better saying, the path that I would have chosen :)

Owner

horst3180 commented Jan 26, 2015

Hi,
that's a valid question. The main reason for me to choose Sass was the fact that Adwaita is using Sass too. I made the structure of Vertex as close as possible to it, because this makes it easier to borrow code from Adwaita, i.e. changes for new gtk versions.
The whole ruby thing is a necessary evil I guess, but it works quite nicely on Arch with ruby-sass installed from the AUR

Contributor

vltr commented Jan 26, 2015

Oh, strong argument. Ok, so, Sass it is! :) I usually use renv, it works quite nicely too (after banging my head against the wall for sometime). Well, I'm working on that pull request for different positions of dash-to-dock. After, I can give a try on the Sass version :)

Cheers,
Richard.

Owner

horst3180 commented Jan 26, 2015

I added some instructions on how to get going with sass. I decided to use bundler to get the sass version specified in the Gemfile. Now you just need to install ruby and execute

gem install bundle && bundle install
Contributor

vltr commented Jan 26, 2015

Yeah, bundler is a great tool for that - I remember the time where Redmine (for example) had to be installed according to a matrix of dependencies specified in their wiki pages ... lol. I'll git it a try @ home :)

Contributor

vltr commented Jan 31, 2015

Quick question: what's the Sass status? I'm on it, but I think just the GTK themes are under work, while the GS theme is still "manual", right?

Owner

horst3180 commented Jan 31, 2015

Yep, the 3.14 theme is pretty much completed, given there aren't some huge dealbreaker bugs, but it's looking good.
The sass-port-3.16 branch is synced to the latest Gtk changes, but I'm still fighting with the new serverside window decorations that replace the metacity theme format. It breaks the titlebutton theming I use for the theme, which is more of a dirty hack, so I deserve it, I guess :)
The GS theme is still plain css, but the gnome folks are rewriting the Adwaita GS theme in Sass for 3.16, but it's still in early stages.
So I guess a Sass rewrite for the Vertex GS theme would be a goal for 3.16, since the current theme is already broken with the gnome-shell git version and it really needs some restructuring.

Contributor

vltr commented Feb 1, 2015

Wait, Gnome changed the window decoration system? Okay then ... Let us hope it'll be something more "sophisticated" then XML. Everytime I see XML, "it's hammer time" plays in my brain 🔨 ⌚️ 😝

Anyway, besides that, can you point me the repository where the Adwaita GS theme in Sass is? I think it's worth to take a look. If you don't mind, the new window window decorator system too 😃

Best regards,
Richard.

Owner

horst3180 commented Feb 1, 2015

The Adwaita GS theme is here (in the data/theme directory) https://git.gnome.org/browse/gnome-shell/tree/?h=wip/sass

The window decorations now pick up the styling information from the gtk theme. The ssd titlebar is available as .header-bar.default-decoration.
This is what I did in Vertex to achieve the same look as before

.header-bar.default-decoration {
  padding-top: 0;
  padding-bottom: 0;
  background-image: linear-gradient(to bottom,
                                    $metacity_bg_a,
                                    $metacity_bg_b);
  border-bottom: none;
}

.header-bar.default-decoration .button.titlebutton {
  padding-top: 3px;
  padding-bottom: 3px;
}

Unfortunately it seems now impossible to theme the titlebuttons individually. In Vertex for example the close button was red on mouseover, maximize was green and minimize was yellow. This is possible because in the client-side decorations the titlebuttons are children of a GtkBox, so they can be individually styled with .titlebutton:last-child, .titlebutton:first-child, etc. However this trick doesn't work with the server-side decorations.
See here for a comparision:
before
after

In the 3.16 branch I decided to use a generic background-image for the hover effect and make the icon visible on hover. This makes the buttons distinguishable again. There's one problem with this, though. I can't control the appearance of those icons, because they are part of the icon theme. With most icon themes the hover state will now look wrong, because the icons are too big. The only solution seems to be to ship seperate icons, which have to be installed by the user. It's not convenient but it should work.

Default icons look strange:
buttons2

Custom icons look awesome:
buttons

Contributor

vltr commented Feb 1, 2015

Thanks for the info. Well, that is something awkward thinking about Gnome, but let us hope that there will be something to do about before 3.16 hits a stable release, or ... Ditch the code a little bit to see if there isn't anything hidden there. I mean, how's default Adwaita on 3.16?

Owner

horst3180 commented Feb 1, 2015

Default adwaita doesn't do this titlebutton trickery. It basically works the same as in 3.14. I could do this too but it doesn't look as good in my opinion and want to keep those titlebuttons.
I'll see if I can find something to make this work better, but ideally I would need different classes for the buttons, like .titlebutton.close, .titlebutton.maximize, etc. That would basically fix everything. Maybe I'll try to convince the gnome people to implement this.

Edit: That's how it would look like if I did it like Adwaita, but I'm not a big fan of it

buttons3

Contributor

vltr commented Feb 2, 2015

Yeah, I see now the question. They could do these extra classes, of course it would make it a lot easier to customize (I think this is obviously the goal of these classes), specially if the theme doesn't depend on extra icons to make it look good (while the minimal is required from users, the best are the results). Like I said, I'll read the code as soon as I can to verify if there aren't things like that already implemented -- if you didn't already. Now, a simple question: besides this issue with window buttons, you mentioned a problem with the new decorator engine. Is this problem specific to maximized windows (no titlebar)? Or it is exactly this one you are describing? :)

Contributor

vltr commented Feb 2, 2015

PS: I'm thinking in make a install script for the theme (pure bash), with options based on the Linux distro / WM / user privileges and options. Would that be ok with you ?

Owner

horst3180 commented Feb 2, 2015

An install script would be awesome :)
When it comes to the window decorations I think the buttons are the only problem for now.
I read through the mutter code a bit and I only found out that all buttons have a generic .titlebutton class, also I didn't find a special widget structure that would enable button specific theming like before, but I'm not very familiar with gtk programming so I might have overlooked something.

Contributor

vltr commented Feb 2, 2015

Ok, a install script it is! :)

Perhaps Gnome folks may have put something, which you can find via selectors, let's say, first or last; but that would f* people that use close / maximize / etc buttons on the left side :)

Maybe another property? Hmmm (I wondering out loud). What's the name of the new decorator? Last time I programmed something using Gnome was with Vala to fix some Elementary OS bugs, but people there were more "design directioned" than "let's not make a code mess because of some design features". Anyway [...].

Owner

horst3180 commented Feb 2, 2015

The decorator isn't new, it's still mutter. It just doesn't load metacity themes anymore. I've tried some combinations with :first-child, :last-child but it didn't work and as you have mentioned it would break relatively easy for people using other button layouts.

Contributor

vltr commented Feb 2, 2015

Okay ... Still Mutter, but the metacity format is now out of the game.
Something like that?

On Mon, Feb 2, 2015 at 10:37 AM, horst3180 notifications@github.com wrote:

The decorator isn't new, it's still mutter. It just doesn't load metacity
themes anymore. I've tried some combinations with :first-child, :last-child
but it didn't work and as you have mentioned it would break relatively easy
for people using other button layouts.


Reply to this email directly or view it on GitHub
horst3180#50 (comment)
.

Owner

horst3180 commented Feb 2, 2015

Yes, the metacity format has been replaced by css.

Contributor

vltr commented Feb 2, 2015

Well, at least this is good news :)

On Mon, Feb 2, 2015 at 10:47 AM, horst3180 notifications@github.com wrote:

Yes, the metacity format has been replaced by css.


Reply to this email directly or view it on GitHub
horst3180#50 (comment)
.

Owner

horst3180 commented Feb 2, 2015

Yeah, but the new css theming is very limited compared to the xml format. While the latter was a real pain to work with, it was extremely flexible.

Contributor

vltr commented Feb 2, 2015

Yeah, that will probably be a problem for a while, since it's a new feature
and it always comes in little baby steps. The good news, for me, is that
now all Gnome can be themed using CSS :)

On Mon, Feb 2, 2015 at 10:53 AM, horst3180 notifications@github.com wrote:

Yeah, but the new css theming is very limited compared to the xml format.
While the latter was a real pain to work with, it was extremely flexible.


Reply to this email directly or view it on GitHub
horst3180#50 (comment)
.

Owner

horst3180 commented Feb 2, 2015

That's true, but I'm not sure if they are willing to reimplement those features, since it works with Adwaita and they may see no reason to fix it.

Contributor

vltr commented Feb 2, 2015

That may sound true, specially if you think about all the features that are
not available to configure, like mutter's drop-shadow on running windows.
It's quite easy to change, but it is hardcoded. The reason? I don't know.
The folks from eOS made this optional using dconf, and it was also a quite
simple change!

In the other hand, they're (Gnome Team) giving us some tools far more
advanced then before (like Mutter or GS) but, since documentation to
examples and specially user feature requests, they're failing miserably,
IMHO :/

On Mon, Feb 2, 2015 at 11:17 AM, horst3180 notifications@github.com wrote:

That's true, but I'm not sure if they are willing to reimplement those
features, since it works with Adwaita and they may see no reason to fix it.


Reply to this email directly or view it on GitHub
horst3180#50 (comment)
.

Owner

horst3180 commented Feb 16, 2015

Specific titlebutton classes have been added to Gtk yesterday and I'm sure patches for mutter will follow before the final 3.16 release. That's pretty good news :)

Contributor

vltr commented Feb 16, 2015

Yeah! That's good news :) Sorry I haven't given much attention to your
project. I'll try to make the install script this week. Since I do not use
Ubuntu, I'll leave some hooks so specific portions of the script can be
filled (like Ubuntu Software Center).

Cheers,
Richard.

On Mon, Feb 16, 2015 at 10:24 AM, horst3180 notifications@github.com
wrote:

Specific titlebutton classes have been added to Gtk yesterday and I'm sure
patches for mutter will follow before the final 3.16 release. That's pretty
good news :)


Reply to this email directly or view it on GitHub
horst3180#50 (comment)
.

Owner

horst3180 commented Feb 16, 2015

No worries, just do the things when you have some time to spare :)

@horst3180 horst3180 closed this Mar 13, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment