Comments (10)
Continuing this conversation here: #14
from hyper.
Ps.: If that is an acceptable solution, i'd prepare it in a PR. :D
from hyper.
Great idea!
I would recommend using a styles.css
file, because it prevents people from complaining about having to use a specific subset of CSS (like Less). If someone wants to use Sass/Less, they can still set up a simple build task and compile it.
Maybe we should also put a config.json
file into ~/.hyperterm/
then? The readme states "Define approach to conf management" as a todo item.
from hyper.
.less
is just a different format, essentially, that extends css rather then limiting it. It also comes with features that could be beneficial, like variables, that could be useful when it comes to theming.
I think if with this a ~/.hyperterm/
directory is introduces it would make sense to also use it as the location for a config.js
. The directory can also hold things like themes, packages/plugins, caches and logs.
from hyper.
.less
is just a different format, essentially, that extends css rather then limiting it. It also comes with features that could be beneficial, like variables, that could be useful when it comes to theming.
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.
from hyper.
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 .less
as an option, with the compiler included and configured, as some find it more readable than plain css, but that could also be solved via a package/plugin.
from hyper.
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! 😊
from hyper.
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.
One option, doesn't imply the other(s). Atom offers style.less
, but not Sass and PostCSS for example.
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" .less
, the focus in this issue is adding a way to customise the style easily, style.css
the primary solution/approach, everything that can compile to this is an idea and optional.
from hyper.
One option, doesn't imply the other(s). Atom offers style.less, but not Sass and PostCSS for example.
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!
from hyper.
I think CSS is enough and we most likely will not need a preprocessor for couple reasons:
- we don't have a lot of selectors nesting
- not so many font styles and variations in font sizes, etc..
- we can work around not using mixins for colours, sizes, etc.. easy
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.
from hyper.
Related Issues (20)
- xterm includes its own hard-coded map
- Supporting the Default Terminal Application setting in Windows
- shell issue
- Unable to get local issuer certificate
- Fails to run on Raspberry Pi OS arm64 HOT 2
- wrong hyper modification HOT 1
- Typed text does not show and screen goes black on macOS Monterey 12.7.3
- Wrong NIC in the speed of data
- The character '_' is highlighted.
- How do I add to the Services TAB of macos?
- windows 10, when use split down / right ,and close, then crash
- [bug] Ctrl+Enter sends ASCII 13 \r instead of ASCII 10 \n
- Black terminal after waking up from sleep
- Unexpected ssh connection disconnection causes Hyper.app to be unresponsive
- Change the theme of Hyper to sync with the OS HOT 1
- once i enter a commond it is not showing any other command that i gave it in past
- Help me with me=y problem HOT 1
- terminal body shows x and y scrollbar when resized HOT 1
- Hyper does not highlight underscores
- top side dissapeared after installation of native-theme HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hyper.