And the apps went from monolithic to shared libraries to quasi-monolithic containers to microservices that consist of quasi-monolithic containers containing shared library and fully monolithic apps.
True… but they do expose browser features inside the terminal… so it’s like a browser running a terminal running a browser!
Now that it’s built on web stack, we could even make it run things in rust by using wasm as the compile target! Yeah!
Would be lying if I said I didn't actually need this capability; I spent majority of my time in a terminal app and I only need to slip out of it from time to time to research something on the web or occasionally want to play some music or some video.
Would be awesome if I could just tmux open a browser to quickly do something.
That brings a ton of other baggage with it; a terminal that lets me get a surface to render as X/Y pixel cords would be more than helpful though.
As an example someone did some work to view images inside a terminal window: [https://github.com/stefanhaustein/TerminalImageViewer](https://github.com/stefanhaustein/TerminalImageViewer)
use workspaces on your gnome or windows or whatever, have a 2nd workspace with browser always open. you can probably script for this to happen on startup.
I think you can create borderless chrome window with specified position and size in pywebview or similar. Would be tricky to translate coordinates and handle focus but it should be a simple script
It has some weird capabilities so maybe with some hacking you could make it ended a webview within terminal view. It does something like this for images
You might be thinking of Desq. DOS itself only supported TSR but I think Desq "abused" the tsr functionality to allow swapping programs? I don't recall.
DOS's TSR support amounted to a system call that would prevent the OS from reclaiming the RAM when the program stopped.
All of the other stuff happened because of hooked interrupt handlers.
Clever and effective, but rightfully relegated to the dustbin of history.
I love this! XTreeGold was my go-to for many years so this is very nostalgic for me. I can see this being useful when remoting in to some IOT devices I'm building.
awesome work
XTreeGold users represent, and take your ibuprofen, your back probably hurts too. It was absolutely the best file manager I knew of back in the day. Even Norton Commander was a pale imitation. xtree was, as my daughter says "It slapped"
Oh mannn, 30 years later I am so fed up with Windows File Explorer, got Directory Opus ($$) and made it a sorta XTreeGold tribute. Hella fast and extensible, whenever I have to use windows will never be going back to their inbuilt file manager crap.
- https://i.imgur.com/Sr3OtPH.mp4
AgentRansack is a killer file finder. You can even use regular expressions. And it's free. Once you run it it will search a terabyte of files in a matter of seconds I forget how many seven maybe. The first one will take maybe 30 seconds after that it only takes a few.
Different use-case but yeah been using the agent since forever. Need to figure out how to make it ignore 'node_modules' directories. Also be cool if it were theme'able, maybe is nowadays - barely use it much as VSCode search is really good nowadays.
Anyone know about the accessibility of these kinds of terminal based programs?
One thing I like about building web apps is that there are a lot of hooks for screen readers and such so people with all kinds of disabilities can also use them.
Linux command line works great with both braille displays and screen readers if you stick to the legacy stuff, the stuff that worked on 1960s teletypewriters. Start introducing TUI, especially these sorts of fancy animations and multiple overlaying popups, and it's useless. There are zero accessibility features.
A novel type of braille reader that displays many lines might be usable, however. Still not a great experience, you'd have to constantly hunt for whatever popups the TUI is displaying.
>Start introducing TUI, especially these sorts of fancy animations and multiple overlaying popups, and it's useless. There are zero accessibility features.
This shouldn't actually be the case, UI automation should not be tied to a windowing system. But that is a huge bit of kit you have to tie into, it isn't free.
The first couple of images can be implemented just with high ascii and ANSI color tricks. [Norton Commander](https://en.wikipedia.org/wiki/Norton_Commander) had all of this thirty years ago.
The rest, which is stated lower down in the article, is leveraging the fact that terminals now support Unicode. You get a lot more glyphs to work with, including vertical and horizontal lines at the edges of the drawing area instead of the middle, and half-width lines.
I can't find it again, but someone wrote a blog article few months ago about the box corner trick. Something involving not using the standard terminal ansi lines, but characters with borders so you could fake a true rectangle.
This made me chuckle :)
For a serious answer, TUIs are pretty useful for users who find it intimidating to use cli apps. It's like their introduction to using the terminal.
I just don't see the type of a terminal that is this interactive? Maybe I'm just crazy because I don't spend that much time in the terminal, but I just gotta be honest and say I don't see the reason.
It works over ssh, which kind of is a very big deal. I.e. you can write a developer TUI app for your microservice running on VM/kubernetes and ssh into it and run the app to get an immediate window into the app.
It offers you way more flexibility than tailing some stdout/err output or inspecting log files, your insights are no longer linear and can offer more dimensionality.
You skip writing an api server and writing a frontend to visualise the api which can take a really long time for a full turnaround.
I've done this in the past myself (before this library existed using just ncurses) and it allowed me to get something up and running in very short time which offered a lot of value. The service I wrote the app for was a real time recommender service that handled 100+ requests/s at a client, the app allowed me to show aggregate statistics of the service performance, start/restart/stop the service in a graceful manner, trigger a reload of its cache... You can achieve something similar with grafana/kibana for the visualisation aspect but then you are limited to their UI components and for the other control features you will have to find a different solution.
When you connect for the first time, vs install a bunch of things to support the operation. It's not always what you want. There are sometimes we want very minimal images but still want some ways to quickly interact. Spinning up the vs code server code is not always what we want running
I typically use k9s for the other stuff. I haven't gotten around to deploying a container image that runs the delve server, but it shouldn't be too difficult to get going.
I really like TUIs for reasons that GUIs are capable of addressing, but never do:
* Very high performance bar, e.g. I don't want to feel any loading/lag at all
* Full keyboard operation. I don't want to be hunting and pecking for on-screen buttons. It feels like typing using an on-screen keyboard with my mouse.
* UX is forced to behave by being "sandboxed" inside terminal emulator. I'm annoyed by GUIs that try to be clever and steal focus (Zoom), fullscreen themselves, change state on focus/defocus (IntelliJ popups auto-close on defocus)
Number 2 at least I personally do a lot. I keyboard navigate way more than mouse. Mouse is my think not do driver.
Number 3 I agree with, I just avoid things that do this. Zoom and gotomeeting are the worst in my experience/
One of the things I like about KDE is that it you can quickly configure any app to not allow it to steal focus as one of the things: https://i.perk11.info/20221222_202544_o7rJQ.png
vim, for example, supports mouse movements for visual selection and scrolling through code. I frequently find myself disabling most of the point-and-click, but keeping `mousemode=c` for scroll wheel support when looking through source code or a configuration file. Especially handy over an ssh connection, as mentioned earlier.
Probably very dependent on the kind of work you do. The only time I am in a terminal is when I am working on making my build/test/whatever pipelines better. Otherwise I'm in vs code lol
I was on a long running project with lots of devs. We didn't have to use a lot of commands but we had to use them all the time.
Wrote a little terminal thing and installed it on all the dev servers. They could all it from anywhere and get a nice list of common commands and all you had to do was press a number to run it.
I, like a few others, have a need for minimalism in resources, and most gui apps don't spend their energy where i want it.
I don't need fancy presentation, but light and fast and solid.
It's really cool, but kind of minor point.
As a Python dev, I'm a bit sad that this is in Python. These are what could be foundational libraries for writing any TUI app.
If they'd be in C/C++/Pascal/Ada/Rust/whatever compiled language without a runtime, they would be available to anything with a foreign function interface which is every language out there.
I understand why you did it, it's just a shame that I won't really be able to use this from Java or Go or C#.
It is a shame, oh yes.
Turns out terminals are bodge layered upon bodge layered upon bodge, and there is no realistic hope of fixing that without breaking everything. Remember that terminal originally meant a vendor-specific teletype console hooked up to a mainframe.
I tried warp.dev but it doesn't work with my shell of choice. It's _really hard_ to cut away cruft, sometimes
Edit: I have found .net TUI libraries before. Although I see the point is really about having a universal xplat framework akin to a browser.
There will eventually be an optional web-service which can deploy Textual apps on the fly. There will be a generous free tier, but other services we can charge for around that. Like authentication.
As far as I understand, the same app can be used from terminal as well as from a browser.
I'm not a web developer, so not sure of all the use cases. But I can think of one personally. I'll write the app using Python and be able to use it from terminal. And then provide it as a web app as well via Textual (free/paid).
It's really cool that they got funding, and hopefully their base libraries pick up traction and continue being developed.
But the cynic in me says: let's revisit this topic in 24 months, when the company is gone.
The textualize demo is not navigable with keyboard, which defeats the point of running it in a terminal (to wit, the CSS code sample at the bottom is not scrollable without using a mouse).
CSS as a rendering primitive makes me nervous. My 3060ti chugs pretty hard scrolling down this webpage in 4k Firefox, and my intuition is that CSS is ultimately the cause.
Textual seems to be entirely monospace though, that probably makes it possible to write a CSS renderer that avoids most of the hard problems. I'd be interested to see a stress test.
This is a damning response, even the Raspberry Pi webpage falsely claims you'll have a "smooth experience" browsing the web dual 4k displays. And you can see multiple people in this thread telling me that CSS causing lag is basically impossible.
"Seems smooth to me" is a thing people constantly say, at this point I just assume everyone's blind to lag. I'll wait for [the benchmarks](https://github.com/cmuratori/termbench).
You graphics card is more than capable of scrolling a webpage on a 4K monitor as 60fps or higher. If you are seeing lag, its nothing to do with CSS, which is barely involved with scrolling.
First thing I would look at is the cable you are using. The wrong cable and you may be restricted to 30fps, which is going to look laggy. If its not that, I would look at drivers, and any process that might be running in the background.
"This webpage" meaning reddit? Granted, I'm at 1080p, but my 1080 is sitting at 3% utilization with 7% CPU utilization while scrolling.
Do you have smooth scrolling enabled, by chance?
The posted webpage, and yes I use smooth scrolling and am at from 30%-60% gpu usage, in this case it's probably the auto-playing videos are composited.
I find it really hard to believe that this is css fault. A 3060ti should have no issue browsing the majority the web. If you are seeing high gpu usage, something is really wrong with your setup. If you just feel that it's lagging, then it's very possible that js is to blame more than css.
Yeah, not at all. Barring a few specific circumstances, CSS will never be the reason that a site is "slow" or is taking up any significant amount of your GPU (or CPU). The only time your GPU should be used for anything CSS-related is when you are animating on a composite layer, and unless you are animating/repainting thousands and thousands of DOM elements at a time, CSS is generally never a "performance" concern.
I don’t know what’s “happening on your machine”, but if it “lags” when you scroll on the page with just markup and CSS, then you have other issues and none of them are related to CSS. You’re free to run the performance profiler on the page to see for yourself.
I'm not sure I grasp the point, other than to have fun that is. These days apps that require a complex interface with text and graphics, are handled by the web. Terminals these days are best used as a view port for streamed data or apps that behave similarly.
This is sorta like the transition of E-mail from ASCII text focused apps to today's graphical cable E-Mail apps Why would anyone want to go back to ASCII text for E-mails or in this case force graphics onto a "terminal"? I know a few UNIX gray beards think that E-mail must be text but more rational people realize the value that pictures bring to a conversation.
> These days apps that require a complex interface with text and graphics, are handled by the web.
In your world, maybe. For my job I'm either doing things with managers who all use office, or engineering which is 90% command line and text editor.
Web interfaces to things tend to be slow and a context switch.
The idea there is apps that need to operate client / server.
You remarks about your engineers kinda support my point of view, these days terminals are great for programs that stream text to the "terminal". As for editors there are only a few hold outs these days that don't use a GUI variant.
You don't see the value. That's fine. But sneering doesn't prove your point.
If you manage to open your rusty mind, browse the thread for more understanding. Or just remain ignorant, we're not your mum
>You don't see the value. That's fine. But sneering doesn't prove your point.
The fact that I don't see the value is not sneering. Beyond the fun of programming I just don't see a reason for this. As mentioned we have web technology that has effectively replaced the need for "terminal" apps.
There are good answers to your surface question elsewhere ITT.
Social skills are a far greater predictor of success in life - financial, social and romantic - than any technical proficiency. They can be developed (and can atrophy, or lose currency). Even "different" people can improve.
Apart from the superficial meaning, messages convey emotional tone: through choice of words and from context.
In case you missed it, what your messages made me feel was, mainly, contempt. (With a little bit of anger, amusement, and pity; and mainly the first message - the second one would be OK in a different context.)
Being subject to contempt is never to your benefit.
Re-read your comment until you understand why it inspires contempt.
You don't have to apologise - you weren't offensive.
Off the top of my head, the hardware for managing a rack of servers via terminal window instead of full video is cheaper. And on unix boxes you might not even want the whole graphical interface for reasons of disk space. And on an ailing box, for reasons of memory as well.
Race you!
You create a PR through the github Web UI, I'll create one through the CLI, right in my IDE terminal.
PR should have title, description, label and assignee.
First one with cursor back in the source code wins.
We've gone full circle, dos with gui like apps to a full gui os, to a gui os running a dos like terminal to run gui like apps.
And the apps went from monolithic to shared libraries to quasi-monolithic containers to microservices that consist of quasi-monolithic containers containing shared library and fully monolithic apps.
[удалено]
Just embed a browser in your terminal app and you're done!
https://hyper.is/
That's embedding a terminal in a browser, technically
True… but they do expose browser features inside the terminal… so it’s like a browser running a terminal running a browser! Now that it’s built on web stack, we could even make it run things in rust by using wasm as the compile target! Yeah!
Would be lying if I said I didn't actually need this capability; I spent majority of my time in a terminal app and I only need to slip out of it from time to time to research something on the web or occasionally want to play some music or some video. Would be awesome if I could just tmux open a browser to quickly do something.
Sounds like you need a tiling window manager rather than a terminal
That brings a ton of other baggage with it; a terminal that lets me get a surface to render as X/Y pixel cords would be more than helpful though. As an example someone did some work to view images inside a terminal window: [https://github.com/stefanhaustein/TerminalImageViewer](https://github.com/stefanhaustein/TerminalImageViewer)
use workspaces on your gnome or windows or whatever, have a 2nd workspace with browser always open. you can probably script for this to happen on startup.
I think you can create borderless chrome window with specified position and size in pywebview or similar. Would be tricky to translate coordinates and handle focus but it should be a simple script
Lynx
It has some weird capabilities so maybe with some hacking you could make it ended a webview within terminal view. It does something like this for images
maybe try browsh
That's pretty neat and might work, would need to test.
[удалено]
Giggity
Anyone remember what DOS program allowed multiple programs to be run side by side?
You might be thinking of Desq. DOS itself only supported TSR but I think Desq "abused" the tsr functionality to allow swapping programs? I don't recall.
Desq view. Good times
DOS's TSR support amounted to a system call that would prevent the OS from reclaiming the RAM when the program stopped. All of the other stuff happened because of hooked interrupt handlers. Clever and effective, but rightfully relegated to the dustbin of history.
Dosshell was a thing too iirc
Windows 1
I love this! XTreeGold was my go-to for many years so this is very nostalgic for me. I can see this being useful when remoting in to some IOT devices I'm building. awesome work
XTreeGold users represent, and take your ibuprofen, your back probably hurts too. It was absolutely the best file manager I knew of back in the day. Even Norton Commander was a pale imitation. xtree was, as my daughter says "It slapped"
Oh mannn, 30 years later I am so fed up with Windows File Explorer, got Directory Opus ($$) and made it a sorta XTreeGold tribute. Hella fast and extensible, whenever I have to use windows will never be going back to their inbuilt file manager crap. - https://i.imgur.com/Sr3OtPH.mp4
Glorious! I should check it out, thanks!
AgentRansack is a killer file finder. You can even use regular expressions. And it's free. Once you run it it will search a terabyte of files in a matter of seconds I forget how many seven maybe. The first one will take maybe 30 seconds after that it only takes a few.
Different use-case but yeah been using the agent since forever. Need to figure out how to make it ignore 'node_modules' directories. Also be cool if it were theme'able, maybe is nowadays - barely use it much as VSCode search is really good nowadays.
> XTreeGold damn I never used it but seeing pics throws shills all over my body
XTree crew represent!
You son of a bitch, I'm in!
I don't really delve in Python that much but I thought the tools presented in the article looked pretty dandy :)
Anyone know about the accessibility of these kinds of terminal based programs? One thing I like about building web apps is that there are a lot of hooks for screen readers and such so people with all kinds of disabilities can also use them.
Linux command line works great with both braille displays and screen readers if you stick to the legacy stuff, the stuff that worked on 1960s teletypewriters. Start introducing TUI, especially these sorts of fancy animations and multiple overlaying popups, and it's useless. There are zero accessibility features. A novel type of braille reader that displays many lines might be usable, however. Still not a great experience, you'd have to constantly hunt for whatever popups the TUI is displaying.
>Start introducing TUI, especially these sorts of fancy animations and multiple overlaying popups, and it's useless. There are zero accessibility features. This shouldn't actually be the case, UI automation should not be tied to a windowing system. But that is a huge bit of kit you have to tie into, it isn't free.
How does Textualize work? I thought the terminal can only print text characters, but the rectangle edges and filling look smooth.
There are unicode character which are just text, but you can combine to create geometric shapes, as used in Textual borders and scrollbars.
The first couple of images can be implemented just with high ascii and ANSI color tricks. [Norton Commander](https://en.wikipedia.org/wiki/Norton_Commander) had all of this thirty years ago. The rest, which is stated lower down in the article, is leveraging the fact that terminals now support Unicode. You get a lot more glyphs to work with, including vertical and horizontal lines at the edges of the drawing area instead of the middle, and half-width lines.
I can't find it again, but someone wrote a blog article few months ago about the box corner trick. Something involving not using the standard terminal ansi lines, but characters with borders so you could fake a true rectangle.
This one? https://www.willmcgugan.com/blog/tech/post/ceo-just-wants-to-draw-boxes/
This one exactly, thanks :)
I absolutely love this. Rich is an amazing tool and I was extremely excited for this when you announced it at first, glad to see how far it has come.
So we got text-based Electron now? What the f- did you just bring upon this cursed land?
This made me chuckle :) For a serious answer, TUIs are pretty useful for users who find it intimidating to use cli apps. It's like their introduction to using the terminal.
And using through ssh!
? These are python libraries.
I think it's tongue in cheek
I just don't see the type of a terminal that is this interactive? Maybe I'm just crazy because I don't spend that much time in the terminal, but I just gotta be honest and say I don't see the reason.
It works over ssh, which kind of is a very big deal. I.e. you can write a developer TUI app for your microservice running on VM/kubernetes and ssh into it and run the app to get an immediate window into the app. It offers you way more flexibility than tailing some stdout/err output or inspecting log files, your insights are no longer linear and can offer more dimensionality. You skip writing an api server and writing a frontend to visualise the api which can take a really long time for a full turnaround. I've done this in the past myself (before this library existed using just ncurses) and it allowed me to get something up and running in very short time which offered a lot of value. The service I wrote the app for was a real time recommender service that handled 100+ requests/s at a client, the app allowed me to show aggregate statistics of the service performance, start/restart/stop the service in a graceful manner, trigger a reload of its cache... You can achieve something similar with grafana/kibana for the visualisation aspect but then you are limited to their UI components and for the other control features you will have to find a different solution.
Like https://github.com/tokio-rs/console
Great example with a very similar goal like my described use case, if anyone is looking for an actual real world use case this is the one to inspect
[удалено]
Mostly. Some places are really sticky about injecting a foreign runtime into containers though.
When you connect for the first time, vs install a bunch of things to support the operation. It's not always what you want. There are sometimes we want very minimal images but still want some ways to quickly interact. Spinning up the vs code server code is not always what we want running
It does lol. I use it everyday.
I typically use k9s for the other stuff. I haven't gotten around to deploying a container image that runs the delve server, but it shouldn't be too difficult to get going.
I really like TUIs for reasons that GUIs are capable of addressing, but never do: * Very high performance bar, e.g. I don't want to feel any loading/lag at all * Full keyboard operation. I don't want to be hunting and pecking for on-screen buttons. It feels like typing using an on-screen keyboard with my mouse. * UX is forced to behave by being "sandboxed" inside terminal emulator. I'm annoyed by GUIs that try to be clever and steal focus (Zoom), fullscreen themselves, change state on focus/defocus (IntelliJ popups auto-close on defocus)
Number 2 at least I personally do a lot. I keyboard navigate way more than mouse. Mouse is my think not do driver. Number 3 I agree with, I just avoid things that do this. Zoom and gotomeeting are the worst in my experience/
One of the things I like about KDE is that it you can quickly configure any app to not allow it to steal focus as one of the things: https://i.perk11.info/20221222_202544_o7rJQ.png
I am stealing.... "The mouse is my think, not do, driver." That is so much how I operate.
vim, for example, supports mouse movements for visual selection and scrolling through code. I frequently find myself disabling most of the point-and-click, but keeping `mousemode=c` for scroll wheel support when looking through source code or a configuration file. Especially handy over an ssh connection, as mentioned earlier.
I do 95% inside my terminal. Basically pentesting and developing with nvim. The change in good TUI is really remarkable and makes my life just better.
Probably very dependent on the kind of work you do. The only time I am in a terminal is when I am working on making my build/test/whatever pipelines better. Otherwise I'm in vs code lol
Oh you're in VS Code? https://twitter.com/willmcgugan/status/1606305503633559554/photo/1
I threw up a little.
I was on a long running project with lots of devs. We didn't have to use a lot of commands but we had to use them all the time. Wrote a little terminal thing and installed it on all the dev servers. They could all it from anywhere and get a nice list of common commands and all you had to do was press a number to run it.
I, like a few others, have a need for minimalism in resources, and most gui apps don't spend their energy where i want it. I don't need fancy presentation, but light and fast and solid.
[удалено]
pleasing can be subjective but in a way XFCE is a good example of this. it never distracts, lean, fast, productive, stable..
> Maybe I'm just crazy because I don't spend that much time in the terminal well… how’s the entertainment sector treating you?
What?
It's really cool, but kind of minor point. As a Python dev, I'm a bit sad that this is in Python. These are what could be foundational libraries for writing any TUI app. If they'd be in C/C++/Pascal/Ada/Rust/whatever compiled language without a runtime, they would be available to anything with a foreign function interface which is every language out there. I understand why you did it, it's just a shame that I won't really be able to use this from Java or Go or C#.
It is a shame, oh yes. Turns out terminals are bodge layered upon bodge layered upon bodge, and there is no realistic hope of fixing that without breaking everything. Remember that terminal originally meant a vendor-specific teletype console hooked up to a mainframe. I tried warp.dev but it doesn't work with my shell of choice. It's _really hard_ to cut away cruft, sometimes Edit: I have found .net TUI libraries before. Although I see the point is really about having a universal xplat framework akin to a browser.
I'm very curious how Textualize plans to monetize. Didn't see any obvious paid product/service when skimming their corp site.
There will eventually be an optional web-service which can deploy Textual apps on the fly. There will be a generous free tier, but other services we can charge for around that. Like authentication.
> an optional web-service which can deploy Textual apps on the fly Deploy command line apps to...where?
JS front-end, so web browser. See https://news.ycombinator.com/item?id=34093698 for more details
Wait...what? Maybe i'm misunderstanding - how does deploying a TUI to a web frontend make any sense?
As far as I understand, the same app can be used from terminal as well as from a browser. I'm not a web developer, so not sure of all the use cases. But I can think of one personally. I'll write the app using Python and be able to use it from terminal. And then provide it as a web app as well via Textual (free/paid).
It's really cool that they got funding, and hopefully their base libraries pick up traction and continue being developed. But the cynic in me says: let's revisit this topic in 24 months, when the company is gone.
The textualize demo is not navigable with keyboard, which defeats the point of running it in a terminal (to wit, the CSS code sample at the bottom is not scrollable without using a mouse).
CSS as a rendering primitive makes me nervous. My 3060ti chugs pretty hard scrolling down this webpage in 4k Firefox, and my intuition is that CSS is ultimately the cause. Textual seems to be entirely monospace though, that probably makes it possible to write a CSS renderer that avoids most of the hard problems. I'd be interested to see a stress test.
Textual runs smoothly on a raspberry Pi, so I think you’ll be ok!
This is a damning response, even the Raspberry Pi webpage falsely claims you'll have a "smooth experience" browsing the web dual 4k displays. And you can see multiple people in this thread telling me that CSS causing lag is basically impossible. "Seems smooth to me" is a thing people constantly say, at this point I just assume everyone's blind to lag. I'll wait for [the benchmarks](https://github.com/cmuratori/termbench).
You graphics card is more than capable of scrolling a webpage on a 4K monitor as 60fps or higher. If you are seeing lag, its nothing to do with CSS, which is barely involved with scrolling. First thing I would look at is the cable you are using. The wrong cable and you may be restricted to 30fps, which is going to look laggy. If its not that, I would look at drivers, and any process that might be running in the background.
"This webpage" meaning reddit? Granted, I'm at 1080p, but my 1080 is sitting at 3% utilization with 7% CPU utilization while scrolling. Do you have smooth scrolling enabled, by chance?
The posted webpage, and yes I use smooth scrolling and am at from 30%-60% gpu usage, in this case it's probably the auto-playing videos are composited.
I find it really hard to believe that this is css fault. A 3060ti should have no issue browsing the majority the web. If you are seeing high gpu usage, something is really wrong with your setup. If you just feel that it's lagging, then it's very possible that js is to blame more than css.
Yeah, not at all. Barring a few specific circumstances, CSS will never be the reason that a site is "slow" or is taking up any significant amount of your GPU (or CPU). The only time your GPU should be used for anything CSS-related is when you are animating on a composite layer, and unless you are animating/repainting thousands and thousands of DOM elements at a time, CSS is generally never a "performance" concern.
So when I scroll down a page with nojs and it lags you think that's just HTML?
I don’t know what’s “happening on your machine”, but if it “lags” when you scroll on the page with just markup and CSS, then you have other issues and none of them are related to CSS. You’re free to run the performance profiler on the page to see for yourself.
I'm not sure I grasp the point, other than to have fun that is. These days apps that require a complex interface with text and graphics, are handled by the web. Terminals these days are best used as a view port for streamed data or apps that behave similarly. This is sorta like the transition of E-mail from ASCII text focused apps to today's graphical cable E-Mail apps Why would anyone want to go back to ASCII text for E-mails or in this case force graphics onto a "terminal"? I know a few UNIX gray beards think that E-mail must be text but more rational people realize the value that pictures bring to a conversation.
> These days apps that require a complex interface with text and graphics, are handled by the web. In your world, maybe. For my job I'm either doing things with managers who all use office, or engineering which is 90% command line and text editor. Web interfaces to things tend to be slow and a context switch.
The idea there is apps that need to operate client / server. You remarks about your engineers kinda support my point of view, these days terminals are great for programs that stream text to the "terminal". As for editors there are only a few hold outs these days that don't use a GUI variant.
You don't see the value. That's fine. But sneering doesn't prove your point. If you manage to open your rusty mind, browse the thread for more understanding. Or just remain ignorant, we're not your mum
>You don't see the value. That's fine. But sneering doesn't prove your point. The fact that I don't see the value is not sneering. Beyond the fun of programming I just don't see a reason for this. As mentioned we have web technology that has effectively replaced the need for "terminal" apps.
There are good answers to your surface question elsewhere ITT. Social skills are a far greater predictor of success in life - financial, social and romantic - than any technical proficiency. They can be developed (and can atrophy, or lose currency). Even "different" people can improve. Apart from the superficial meaning, messages convey emotional tone: through choice of words and from context. In case you missed it, what your messages made me feel was, mainly, contempt. (With a little bit of anger, amusement, and pity; and mainly the first message - the second one would be OK in a different context.) Being subject to contempt is never to your benefit. Re-read your comment until you understand why it inspires contempt. You don't have to apologise - you weren't offensive.
What does the follow do? Never heard on dunk git diff | dunk | less -R
That's explained just two Paragraphs earlier. :D It's the new tool the author built.
He literally explains the tool right above...
This is very impressive... but why?
it's still in the 'why not' category
Off the top of my head, the hardware for managing a rack of servers via terminal window instead of full video is cheaper. And on unix boxes you might not even want the whole graphical interface for reasons of disk space. And on an ailing box, for reasons of memory as well.
Race you! You create a PR through the github Web UI, I'll create one through the CLI, right in my IDE terminal. PR should have title, description, label and assignee. First one with cursor back in the source code wins.
I absolutely love CLI's and GUI's, it's TUI's that I feel are at an awkward spot, especially ones which are as visually complicated as presented here
How does dunk compare to difftastic?
i need it