New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow custom stylesheet #10
Comments
Ps.: If that is an acceptable solution, i'd prepare it in a PR. :D |
Great idea! I would recommend using a Maybe we should also put a |
I think if with this a |
I'm aware of Less' features 😊 However, I generally don't think that it's a good choice since Sass saw the light of day. If you look around the web, you'll notice that the majority of projects have already made the switch to it or PostCSS. And because I don't want to start bikeshedding about what's the best choice when it comes to choosing a build tool (Sass/PostCSS/Less/whatever), my personal recommendation would be to simply go with normal, plain CSS. This also has the great side-effect that we won't have to compile the code before loading it into the application. And as I said: If someone really wants to use one of these tools, there's still the possibility to set up a simply build task using a build tool. What I do think as well is that variables could definitely be useful when it comes to theming. However, I think we're generally better off with using CSS variables. They can be modified in realtime! 🤘 Since Electron already runs Chromium 51, we should be able to easily take advantage of them. |
You are totally right, that plain css would be the right way to go. I wouldn't find it a bad idea though to offer |
Okay! But then we'll have to offer an option for Sass, PostCSS, etc. as well. And IMHO, that's just too much and only confuses people. Also keep in mind that we wouldn't just have to include and configure the compiler, but also make sure that it gets all the predefined theme data (variables, etc.) from somewhere. And this mechanism would have to be different for each of these build tools... I think the perfect setup would be to go with CSS (I think we both agree on this now), but also to not somehow barricade/block the use of tools like Less, Sass and PostCSS (I'm talking about compiling files to CSS before they get loaded into the application). If people really want to use them, they should be able to! 😊 |
One option, doesn't imply the other(s). Atom offers The variables wouldn't be used for theming, but are a useful feature of less, which in css are CSS variables. Pre-compilation would be triggered on app start if a sytle.less file exists and or is updated, and would cache the compiled version for inclusion in the app. And as said, "maybe" |
Exactly! And in my opinion, that's a more-than-bad approach. Simply because of the fact that it forces the user to use a certain syntax even if he/she doesn't want to (as bad as forcing CoffeeScript). I think we're basically wasting performance by compiling stuff on runtime. But like you said, let's just implement the basic mechanism for CSS and then see how it goes from there! |
I think CSS is enough and we most likely will not need a preprocessor for couple reasons:
Hyperterm is 1 consistent and clean window. Atom has so many things going on starting from their settings/packages page to the sidebar with project treeview etc.. However, the idea is really great! I love it. |
Continuing this conversation here: #14 |
Allowing a custom stylesheet offers a lot of possibilities to make hyperterm like home, for example changing the font and font-size.
It could be implemented with the simple convention of having a
style.css
(maybestyle.less
) in~/.hyperterm/
.The text was updated successfully, but these errors were encountered: