Main version #19
Comments
|
Hi, @robertpainsi. This is something that I actually had in mind since I started this fork and I think that putting the common files under, say, a In the worst case, creating symlinks would be a 2nd choice, but I would really prefer to have a single common directory that works just as you thought about. Regarding disadvantages, I think (but I can't know for sure) that the original author of the theme created the files multiple times to make it easier for users that only wanted one flavour of the themes. I don't think that this is needed and, even if it is, we can always do this with scripts when preparing to release a new version (which may be something that end users might want to have). Thanks for the suggestions, Rogério. |
|
I guess that what I meant with the previous message is: go ahead and unify the files. Just take care of putting the comments that are in the files and that are informative (such as gotchas etc.) in the common file. It is better to have them well-documented so that we do not forget. |
|
Hi @rbrito! I started the good old merge tool meld to compare the gtk-3.0 folders. In my opinion it's manageable. But bringing the files to a common base is hard without any experience on how to manage multiple css files. Also heavy refactoring has to be done first. What I can do, is, creating a common base by using a diff tool. Maybe it's the best step to begin with. I will ignore the gtk.css file at the beginning because these files are the hardest to merge. The plan would be:
|
|
Darn, wrong button ^^ |
|
First, just to clarify, I'm always talking about the css files in the gtk3.0 theme only. So, I was filtering out the files which doesn't differ (man, I ❤️ the terminal). There are 17 files which all themes have in common. That's great! 😸 Before I continued, I had to check something. As I mentioned in the previous comment, I want to use the @import statement to import the common css file and add all the themes unique stuff below. I start doing this for the gtk-widgets.css file and copied it from MediterraneanDark to the MediterraneanCommon folder. In the MediterraneanDark folder I removed all content from the gtk-widgets.css file and just added the line Now I’m facing a problem. All references to the assets in the css file will point to MediterraneanCommon/gtk-3.0/assets but they should point to the theme itself (e.g. MediterraneanDark/gtk-3.0/assets). Also the theme has some serious problems and is unusable. I came up with a quick workaround but it’s not very ellegant. Creating a link and just adding the code to the gtk-widgets.css will do the job (for now). So by just using this code everything stays the same except the numbers in the calendar will be red. I don’t prefer this solution at all. It’s seems like a hack. Maybe you know a better solution? The changes I made can be inspected here: Summary:
Sorry for the long comment. Here is a 🍠 (9gag joke 😸) |
|
@robertpainsi I'm not really familiar with GTK CSS, but it seems like it has variables like SASS does. Maybe instead of the hardcoded asset URLs, we can have a variable declared in MediterraneanDark's gtk-widgets.css, followed by an import that will use the variable? Like: /* MediterraneanDark gtk-widgets.css */
@currentTheme: "MediterraneanDark";
@import url("../../MediterraneanCommon/gtk-3.0/gtk-widgets.css");/* MediterraneanCommon gtk-widgets.css */
...
background-image: url("../" + @currentTheme + "/assets/background-noise-toolbar.png");
...I don't know if variables can be "seen" within imports and concatenated this way in GTK CSS, but if so it may just work. |
|
Hey, guys! I've just skimmed over this issue and I see you came to the same conclusion as I did. I haven't reviewed in deep the tools which you suggested, yet. For now I wanted to share with you my idea. The first step to solving the "multiple-theme-one-structure" problem is implementing a build process with source tree, target descriptions and target files. A very simple builder can be written in node.js (if something similar doesn't exist on npm).
So this is briefly how I see dev process for multi-variant themes. All questions, suggestions and critic are welcome. I want to apologize, if you have already discussed those things and I just spam, but really I haven't had the time to read and try out everything. PS And sorry if I made mistakes in the brain puke - I'll try to rewrite it on a fresh head. |
|
@dodev I am totally in love with css pre- and post-processors like SASS and Autoprefixer with an Tools for live inspection I think can be found in the wiki of this project. |
|
Awesome ideas guys! @darvelo @dodev Maybe gtk-3.0 is already capable of sass http://worldofgnome.org/adwaita-gtk-theme-is-now-ported-to-sass/ ? Since SASS > CSS !!! this would be awesome! Also the css files have been removed and replaced by scss files in this commit https://git.gnome.org/browse/gnome-themes-standard/commit/?id=c10689c7b2dc1352e7b329f58c9f653e5682dca5 |
|
Sadly not 😿 |
|
I created a PR (only for inspection 😼) with the first results #30 Sorry if there is a lot to read but these steps and further processes are important! It would allow us to create a build system (some unifications still have to be done by hand yet) and then simplifying the code rule by rule by using a superior styling language like sass. |
|
So, these are the last changes I added to #30 but using a new branch (easier to follow and compare). The changes can be inspected here. These changes still ignore issue #24 and #26 atm because I don't know yet which changes can be unified or are needed. Sooo, feedback 😸 |
|
Finally got rid of all the stuff which just has been added as workarounds. Since this is mergeable, I created a pull request. There are no further improvements to make without switching to a superior styling language and creating a real build system. |
|
...and we finally have a sass version with a clean and real Makefile. Check it out! 😼 [Insert awesome party emoji here!] Just run The widget-factory throws no warnings/error. I also compared the master with the sass version directly. To be more precise, the widget factory and nautilus. I added both theme versions to the unity tweak tool and switched between each theme. Nothing changes! Not even a single pixel nor reformatting happens. So the master and sass versions produces the same view/output. (except in the Night/NightDarkest theme. See not related changes below) Since we have a common base and a build process now, the next steps is sass refactoring. Maybe add a make parameter for each theme too because changing something and running the make file will build all themes which may take a few seconds (<5 secs on my laptop). Also fixing some issues and "Spread the word to enthusiast sites" #25 too would be awesome. Not related changes: Thanks to @rbrito @dodev and especially to @darvelo for all the support. |
|
@robertpainsi This is amazing work! 👏 Now we definitely have a good foundation to build from. Some thoughts:
Either way, most of the hard work is now done. Great job! |
None, for all the colors in colors.scss 😨 My purpose was to give them extreme color values atm to immediately see them in the OS, get the related variable and correct them. So, for these colors I couldn't assign a correct color value yet since I didn't know which parts of the OS are effected. css itself changes undefined variables to white I guess or maybe ignores the property completely. Btw: There were three colors I could define. https://github.com/robertpainsi/pkg-mediterranean-gtk-themes/blob/cad144ac32d3cec1cbc8d8138f44ffb7b1fc4994/MediterraneanNight/gtk-3.0/scss/gtk.scss#L43-L46 and I also changed https://github.com/robertpainsi/pkg-mediterranean-gtk-themes/blob/cad144ac32d3cec1cbc8d8138f44ffb7b1fc4994/MediterraneanNight/gtk-3.0/scss/gtk-widgets.scss#L7-L11 . But these are the only changes I made to all the themes after the sass migration and the changes are only in Night and NightDarkest. And there is already an issue #26 which will deal with that. So someone has to look over it again.
That's great! Always wandered what these underscore thingy was 😸 sass also has an watch statement which maybe comes in handy too with those partials.
No, not at all. That's the easy part because you don't have to think. Most has been done by terminal commands and regexp. Only a few things have been done by hand. Now refactoring all the scss files is the most time consuming stuff but with a common base we only have to deal with one version of a file. Sy for the long post. Always writing too much 😼 |
|
Oh, I was under the impression that the MediterraneanCommon dir was the source of all the duplicate code? |
|
k, I should have been more precise. 😸 The common dir is the source of all the duplicate code shared by all themes but the files in the common dir also have to be refactored. Since we can use the power of sass now, we can use inheritance, functions and variables which can define more than just colors to reduce the common scss files and complexity and also improve them overall. Naming the current process 'refactor all common scss' would be a good name for that. 😼 I thought that the csscss tool would help for refactoring. If there is duplicate code in a common scss file, we define them once and let the corresponding selectors inherit them. But I'm completely new to sass, so I'm not sure if that's the best way to do the refactoring... |
|
...and gtk 3.14 has a new awesome tool I found today. The gtk-inspector (https://github.com/rbrito/pkg-mediterranean-gtk-themes/wiki/Tools#gtkinspector). I installed ubuntu 15.04 to test it out. If you do so too, you may have to fix a critical bug by hand in the current release https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1415586 If you run something else than ubuntu, you maybe have gtk 3.14 already. Check it by using the command I also executed The tool let you inspect all the gtk stuff. You can also add custom css code to test the changes in realtime and changing the themes which will only effect the current inspected window. AWESOME² See the inspector live in action https://mclasen.fedorapeople.org/inspector.webm The only thing we have to bring back in sass are css-variables since you can use them in the inspector. Numix already has tried to do that, but it's not pleasing me at all. The variables there are defined at the beginning but never used at all because sass replaces variables with values... So, to use the inspector more efficiently, we have to prevent sass to replace sass-variables by its value but replace sass-variables by gtk/css-variables. Maybe some trick like with the gtk shade function which is defined in _functions.scss will do it? |
|
css:
Bullsh*t: The Adwaita and Numix team already do it the right way. My fault, I will add all the @define-color stuff like the other teams did. Nevertheless this doesn't solve the redundancy. |
|
@robertpainsi Thanks for adding that tool to the wiki. That will help debugging a lot. I think you're right about using a color function for debugging. I've done some work figuring it out. You can define a Custom Sass function in Ruby and use it with a global var and an input string like so: $debug: false;
$button-color: #00F;
@function theme-color($color-name) {
@return if($debug, unquote("@#{$color-name}"), themeColor($color-name));
}
.blue {
background-color: theme-color(button-color)
}Then have a custom function that will output the actual variable value: # file: themeColor.rb
module Sass::Script::Functions
def themeColor(colorname)
assert_type colorname, :String
environment.caller.var(colorname.value)
end
declare :themeColor, [:string]
endNow when you call $ sass -r ./themeColor.rb sassFile.scssOutput when .blue { background-color: #00F; }Output when .blue { background-color: @button-color; } |
|
Oh, I was updating my previous post the same time you posted your previous comment. sorry! 😸 I changed my mind about the usefulness of showing those variable names instead of color values in the css files. I was always thinking about using the inspector. Because you can change colors and stuff live, you definitely need those defined color variables. But in the css code of the theme itself, it isn't important at all. I would also say that the real color code is more important because you can pick the color with some color picker and search it in the css file. So, we should define the colors like here https://github.com/shimmerproject/Numix/blob/sass/gtk-3.0/scss/_colors.scss, so we can use them in the inspector, but don't use gtk variable names anywhere else. Imo I don't see any need for this feature anymore. |
|
You're right. 😄 I think the way Numix does it is best. |
|
k, sy for the circumstances! But it's good to see that sass could handle something like that! Since you are already into the color sass/gtk variable stuff now, maybe you have an idea to fix the redundancy? As you can see, the variables are declared two times. Once as sass variables and once as gtk-variables. It would be awesome if we could merge this in some kind of oneliner. But I'm not sure if it's worth it and maybe it's a stupid idea again... |
|
I think something like that would have to be done in Ruby. I really don't know much Ruby at all, but it would probably work similarly to what I posted. Hypothetically, you'd have a Sass function taking a name and a color, and passing them to Ruby to alter the Sass environment at a lower level. It's not really a supported feature, and kind of hacky, so the redundancy might actually be the cleaner way, ironically. 😆 |
|
Thanks @darvelo ! The cleaner way it is. 😸 For now, I will ease back the throttle (slow down). Everything has been prepared for a big sass refactoring process. Also I'm not very familiar with sass, I'll leave further decisions to sass-experts. I add some notes I took during the common version process here. Maybe I'll create issues for each point. Nevertheless, the current step is luring more sass/gtk people to this repository. 😼
|
|
@robertpainsi Thanks so much for the work you've put in so far. It'll go a long way to making this theme as current as possible. Those are all good notes to keep in mind for the future. If you could make a separate issue and copy them there, it would allow others to easily follow the current state of the project. It's a very interesting point you made about condensing everything into MediterraneanCommon and just using different variables for each derivative. It's a real insight that all themes might be reduced to a single scss file with their own variable values for colors and asset pointers! |
|
Btw: I'm just taking a few days off for now but will continue working on this repo next week again. With less spare time on my hand, the next improvements/fixes I'll make will take much much longer. I have written all the issues, as you suggested, but haven't posted them yet. Since the changes haven't been merged into the master yet and there is no other branch in this repo to link to. @rbrito has to do that as mentioned in #29 (comment) and #29 (comment) |
|
@rbrito, it might be time to merge the |
|
How do we proceed? Imo it's mergeable into the master too. I'll create a PR #33 😼 If it's merged, we can start getting more users and contributors! 🎉 The only thing left is how to provide the themes? Maybe we reuse the PPA to provide stable releases? @rbrito : You should also consider to give some rights to other contributes. So we can support you with Issues, PR reviews and other maintaining stuff! 😸 Everybody here is professional and won't merge his own PRs. |
|
Looking through the compare I found an error. Since I moved the files to a src folder but then back in the root again, all the xfm4 images which where defined in the .gitignores have been ignored. I just wasn't aware of other .gitignore files than the main. 😾 I re-add the missing images and removed the unnecessary .gitignore files. |
|
The sass branch is the branch I'm currently working on. I also did some unification without creating PRs so you guys couldn't review them. I'm sorry... That's bad practice. 😾 I createe a sass branch in this repo (https://github.com/rbrito/pkg-mediterranean-gtk-themes/tree/sass) and start creating PRs for this branch. We don't have to hurry to merge the branch into the master. 😼 |
|
Hi, Robert. On Feb 28 2015, Robert Painsi wrote:
The smaller, bite-sized the changes are, the sweeter. :) Oh, BTW, don't Ideally (but that's for the future), we would like to have unit tests or That would be an extra, automatic layer of verification on what we humans
Is there something that we could sort-of release so as to get a wider All this kind of disclaimer (e.g, which is the most tested theme, themes for Oh, I will be about 1 week and a half without internet access, which means Thanks, Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA |
On it! 😸
Yeah, that would be awesome. The more automated it is the better.
I'm still working on some tickets which definitely should be done before the release. I hope that I can fix them before you come back 😸.
The nightmare of every computer scientist. 🙀 |
|
Oh, something important came up! I'll start working on the issues after 13th |
|
And an important exam came up... It's one of my last ones... So, have to expand my pause to 30th. 😳 |
Hi!
Changing/Updating/Fixing things for these awesome themes always includes fixing it for every single theme the same way. Nobody wants to do that and it's also error-prone.
So how about creating a main/default version of all css? So each theme just imports the main theme and adapt settings which are necessary. The original creator already thought about that by moving all colors into a single file.
Since I'm not familiar with "themeing" at all (but with css) I have to ask if its possible or if there are any drawbacks?
The text was updated successfully, but these errors were encountered: