Toolbar elements invisible, then reappear

[wuz352]

Hello:

I have taken two themes from online and stitched them together. One strange thing that has happened is that the toolbar on the File Manager, and other toolbars throughout actual system interaction, simply is invisible. After I select the elements, they reappear, though. I've attached a photo of how it looks. I've looked thru the "cinammon.css" file and been unable to change this. Does anyone know of a solution (did not see anything like this after multiple searches)?

A secondary minor note is that some applications have the same old selection color. Can anyone tell me where to find this selection-color element in "cinammon.css"?

Cheers,

-will

[Penn]

Hello:

I have taken two themes from online and stitched them together.

Clarify? What exactly did you do when you "stitched theme together"? What 2 themes and where did you get them?

One strange thing that has happened is that the toolbar on the File Manager, and other toolbars throughout actual system interaction, simply is invisible. After I select the elements, they reappear, though. I've attached a photo of how it looks. I've looked thru the "cinammon.css" file and been unable to change this. Does anyone know of a solution (did not see anything like this after multiple searches)?

Again, I'm not completely sure what you mean here but if the answer to the above question is what I am thinking you simply broke the theme and all sorts of odd things happen when that is the case.

A secondary minor note is that some applications have the same old selection color. Can anyone tell me where to find this selection-color element in "cinammon.css"?

Cheers,

-will

Very few things are controlled by cinnamon.css. Panel (the whole bottom bar) and it's applets including the menu, alt+tab window switching, some dialog boxes and expo or other elements of workspace switching. In short, if it doesn't change when switching just the bottom of the 4 theme sections in theme settings labeled as "Desktop" then cinnamon.css has nothing to do with that element. Window borders is the folder for metacity and everthing else is either gtk-2.0 or gtk-3.0 folders (all of this assuming you really are using Cinnamon inxi -Sz).

[wuz352]

I had forgot to mention that I had tried gtk-2.0 and gtk-3.0 for the selection-color element in the last question of my post.

Unfortunately you've only told me information I already know, Penn; very StackOverflow/Quora/etc. answer. I'm not trying to be a jerk, but the condescension is palpable as much of your critiques already tracks in my original post.

[Penn]

I had forgot to mention that I had tried gtk-2.0 and gtk-3.0 for the selection-color element in the last question of my post.

Unfortunately you've only told me information I already know, Penn; very StackOverflow/Quora/etc. answer. I'm not trying to be a jerk, but the condescension is palpable as much of your critiques already tracks in my original post.

You didn't answer me. Instead of attacking me you might try by starting there. I can't answer without more information. Even that answer might lead to more questions but believe me, the goal is to help.

If you really want to derail your own thread instead, the way personal attacks on forums frequently do derail a conversation, you could enlighten me how I was engaging in palpable condescension. I attempted to answer without knowing your level of knowledge and experience. Not seeing condescension.

[wuz352]

Aren't all Linux Mint Cinnamon themes built/schemed/etc. alike? This is what I know, or have read. I simply thought I skipped/missed/deleted/didn't-have an "unhover" element in the CSS files or something.

I know enough CSS that I localized elements of theme A that I didn't like and replaced them with ones from theme B I did like, simply updating theme A. They were both Windows 10 themes I customized to look more like a Linux Mint setup. I didn't want to get pot-shotted (because I don't even like Windows), so I figured it wasn't worth mentioning. I believed that all elements relating to themes were standardized in Cinnamon, therefore I could discuss the primary issue. This was fueled by being able to so easily interchange elements in totally different themes. If this isn't the case, then I've massively misunderstood Cinnamon themes and apologize.

I'm not trying to derail my own thread. What's the point of that? You're coming in hot, man. I'm Level 1. I am a beginner, maybe average. The way you prompted me for more information seemed condescending because I don't know anymore than posting what I had already given, and I thought I did a decent job (Maybe I didn't, I don't know.).

[Penn]

All the cinnamon.css files I've seen are pretty much consistent. The Cinnamon usage of themes being 3 part is not standard in the Linux world, as far as I can tell but I don't have much experience outside of that one DE.

GTK themes, which control most of the elements you see in all Mint versions can be drastically different from one theme to another and from one minor version of GTK3 to another. If you look at Mint-X gtk-3.0 css files and compare that to the way Mint-Y uses css there is a huge difference. If what you refer to as theme-A is more similar to Mint-Y then it might be SASS which should not be modified in the way you are attempting. Due to the way it integrates into the system those themes should be altered at the source code level then compile and install. I don't know if that is the case with your theme since you haven't let me know what you are using.

There is also the possibility of mixing minor versions such as GTK 3.16 and GTK 3.18. A lot of the sections in a theme are compatible between both but not all.

Both of these things could potentially give the issue you are experiencing as far as I know. If a reader of your post had ever run into the exact situation you describe (if they even understand it correct since I see at least 2 interpretations) then they might be able to give you a concrete answer. I haven't had your experience or if I have it was easy enough for me to fix I forgot about it. That leads me to the only recommendation I can give at this point since doing things the way I'm about to suggest have made potentially difficult situations easy to diagnose and fix.

What I would do if I were you is start over. Go back to Theme-A as it was written. Limit the changes you make at a time and take them for a spin, by which I mean reboot and use it for a while across multiple apps. Once you finally isolate which line you altered that caused the new behavior, if you are still having issues figuring it out, you can come back with more specific information of what you changed, both from and to. GTK is just too complex for a person to guess what is not right for you (I'm guessing even a person with much more experience than I have would not be able to diagnose this issue with the current information).

[JosephM]

If what you refer to as theme-A is more similar to Mint-Y then it might be SASS which should not be modified in the way you are attempting. Due to the way it integrates into the system those themes should be altered at the source code level then compile and install.

You're misunderstanding how this works. Technically there is no difference between the .css files in Mint-X and Mint-Y that you find /usr/share/themes. There is obviously a difference in the formatting of the actual files. That's because one is hand written and the other is generated by another tool. You can modify both to your hearts content The difference is on the developer side. The Mint-Y css files are generated by SASS. The reason for this is ease of maintenance. With SASS if I'm fixing a bug, I can usually fix the problem in one file and then run a script. This script rebuilds the needed css files for all the color schemes. This is much better on our end then how it works with MInt-X. Because we have 10 color variations, that means currently I have to update the problem by hand in 10 different files. That's a PITA when it comes to maintenance. Mint-X in our github repos will move to SASS, likely for Mint19. Just to greatly reduce the time needed to keep them updated.

In the end, how the css is created has no effect on you as a user trying to make modifications outside of the formatting not being as neat and clean to work with.

[Penn]

If what you refer to as theme-A is more similar to Mint-Y then it might be SASS which should not be modified in the way you are attempting. Due to the way it integrates into the system those themes should be altered at the source code level then compile and install.

You're misunderstanding how this works. Technically there is no difference between the .css files in Mint-X and Mint-Y that you find /usr/share/themes. There is obviously a difference in the formatting of the actual files. That's because one is hand written and the other is generated by another tool. You can modify both to your hearts content The difference is on the developer side. The Mint-Y css files are generated by SASS. The reason for this is ease of maintenance. With SASS if I'm fixing a bug, I can usually fix the problem in one file and then run a script. This script rebuilds the needed css files for all the color schemes. This is much better on our end then how it works with MInt-X. Because we have 10 color variations, that means currently I have to update the problem by hand in 10 different files. That's a PITA when it comes to maintenance. Mint-X in our github repos will move to SASS, likely for Mint19. Just to greatly reduce the time needed to keep them updated.

In the end, how the css is created has no effect on you as a user trying to make modifications outside of the formatting not being as neat and clean to work with.

Actually I didn't misunderstand how it works, at least in what I was trying to say. In an effort to say it in an easy to understand way I now see I was entirely inaccurate though, so thank you. I guess I should have just said editing SASS generated doesn't always work the way expected, which, I believe, is why you have even said a person probably shouldn't edit them in this way in the past. One example of that is the tree view in the Nemo side pane in one theme I was altering for 3.22 had 3 different entries that affected the selected color there and multiple lines effected the field that is a button that can't be pressed in the theme settings. I suppose that same condition could easily exist without SASS but haven't encountered it. Doesn't change that you are right here, I know.

There was some new information for me in your response though, so thanks for that too. Always appreciate your input

[wuz352]

I appreciate the help y'all have given me. As you can probably tell, the issue is very frustrating. I apologize if I came off as brash, but I'm still quite new and worried how others might see that.

It's taken a little time to retrace my steps and figure out where the W10 themes were from because this project has been done over the last six months.

theme-A: Windows 10 Dark Theme by B00merang-Project
theme-B: N00bslab W10 Theme [Seems to be based of B00merang's W10. Menu-bar elements like calendar, wifi, user, were taken from here and placed into theme-A.]

It took a lot of time, but I finally found that something in gtk-3.0 had messed up. I assume I either deleted a small area of code by accident, or a file was deleted by accident. Not really sure because I ended having to completely replace the files in the gtk-3.0 folder with the original W10 B00merang files; updating color scheming after this was completed. I tried extensively to isolate the individual file and/or code, but had zero luck.

This thought occurred to me after I posted on here, and I think it's true, that I simply lucked up and got all the elements I'm using from the same initial source, thus being the only reason the resulting theme I have works, haha.

On another note, I ended finding where all of the applications schemes are because of this prompting and amended the color scheming for applications in those files. So, the whole theme is now uniform system wide.

It's fixed, though: Thank you for your help!

Cheers,

-will