7 ms·

The Xterm Window Manager Homepage

104 points by 6581 5y ago

cpach 5y ago
Is Java really faster than Electron? I wouldn’t have guessed that, but if it’s true: Hey, cool!
- Nux 5y ago
  Java can be very fast indeed. It gets a bad press because many programs coded in it can be quite heavy and bloated.
  - cpach 5y ago
    TBH I think this is the first time I’ve seen a TUI done in Java. (There might be more examples out there but I can’t come to think of any right now at least.)
    - laumars 5y ago
      A TUI is ostensibly just a command line application with an event loop and plenty of {ESC} characters being written to STDOUT. And I can assure you there are no shortage of Java applications that run headless.
    - tyingq 5y ago
      A couple of TUI libraries for Java: http://www.pitman.co.za/projects/charva/Screenshots.html http://www.pitman.co.za/projects/charva/Screenshots.html https://github.com/mabe02/lanterna https://github.com/mabe02/lanterna And, lower level, there's jCurses, which despite the name, also works on Windows: https://github.com/kba/jcurses https://github.com/kba/jcurses
      - tyingq 5y ago
        Apparently, the linked project also separated out their Java TUI into a separate project called Jexer. https://gitlab.com/klamonte/jexer https://gitlab.com/klamonte/jexer
- laumars 5y ago
  I’m surprised you’re surprised. Electron runs like a dog on modern systems while Java has been used in enterprise applications since the 90s. They’re not even in the same league. But then there isn’t much out there that even comes close to the performance overhead of Electron.
  - wk_end 5y ago
    Nonsense. Electron is a memory hog and a disk space hog, but perf-wide V8 is incredible given what it has to work with. Definitely within spitting distance of Java.
    - laumars 5y ago
      Electron is more than just V8 and in fact most of the UI elements (since we are talking about UI usage here) fall outside of V8. But it’s also worth noting that JavaScript isn’t as close to Java as you claim. Not only do the benchmarks posted in this discuss but that argument to bed, but also the existence of WASM too (is JavaScript was really that good then there would be no need for WASM).
      - cxr 5y ago
        Electron "runs like a dog" because Electron development is what you get when you let the dominant culture associated with NPM-and-GitHub-driven consensus take over. It's a culture that not just tolerates bad development practices but outright encourages them while discouraging good ones. (Hell, the majority of Electron/NodeJS programs are written in a style that struggles against the language and the bindings exposed by the host environment.) If most Electron and NodeJS programmers wrote code the way that they'd be forced to write the same program in Java, or if they wrote code like the JS that was checked into the Mozilla source tree for Firefox's UI 15 years ago to run on sub-GHz machines (or that was powering Netscape's UI 5 years before that), then the impression that JS is "slow" relative to Java wouldn't exist. There is no shortage of abominable enterprise software of yesteryear written by mediocre Java programmers. It's just that their currentgen counterparts are mediocre programmers working with React/Electron/NodeJS instead.
- xiaq 5y ago
  Java programs are slow to start because of all the JVM overheads, but after that the performance is probably between 1x and 2x as slow as C (it depends a lot on the workload, of course). Java is definitely not a slow language in general, just has slow startup. The slow startup time is the reason why Java is considered high performance in "enterprise software", but has a reputation of being slow among developers, especially non-Java developers. "Enterprise software" is usually long-running server-side programs, so you barely care about the startup time. But if you're using Java programs as part of your development workflow you'll tend to start and restart them repeatedly and the startup time can get really annoying. Java's GUI libraries also tend to be not very well optimized, which further contributes to people's impression of Java's performance. In the case of this particular project, even though it's a terminal application, since it's a WM you'll likely start it once and leave it running for a pretty long time (as opposed to programs like "ls" which you run again and again), so this is in fact a good place to use Java. You can also use GraalVM to compile Java programs ahead of time these days, and get much faster startup.
  - capableweb 5y ago
    > You can also use GraalVM to compile Java programs ahead of time these days, and get much faster startup. Just wanted to add a note that there is a tradeoff involved, as programs compiled with GraalVM will have worse performance compared to running directly with the JVM, but the startup speed will be faster. For CLIs, GraalVM is a god send. For long-running servers/daemons, JVM is still king.
    - pjmlp 5y ago
      For CLIs, AOT compilation has been available since around 2000 for those whose employers could afford commercial JDKs, or try their luck with gcj. Nowadays both OpenJDK and OpenJ9 offer free JIT caches with PGO data, GraalVM isn't the only free beer option.
      - capableweb 5y ago
        > AOT compilation has been available ... commercial JDKs, or try their luck with gcj > OpenJDK and OpenJ9 offer free JIT caches with PGO data As someone who never been exposed to either of those options, what kind of startup times do they offer compared to GraalVM? With GraalVM compiled Native Image I get same startup performance as any random Go program, would those offer the same performance when it comes to startup? Is there any tradeoff regarding long-term performance for daemons and similar?
- yung_steezy 5y ago
  I believe Java web frameworks still come out on top in terms of performance speed.
  - bitwize 5y ago
    C++ and Rust frameworks are faster. But Java is in like the top 3 or 4.
  - laumars 5y ago
    Near the top. They never came out on top because languages like C++ would out perform (and now we have Rust too). But Java is certainly up there. That said, recently even a lot of the other languages have made some huge optimisations in the web server space too and so Java doesn’t even dominate amongst the byte code languages like it used it https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ That all said, comparing Java to Electron is like comparing a sports car to a camper van.
- GuB-42 5y ago
  In the hierarchy of performance, Java is what comes just after native C++, it may even be faster than Rust because while Rust is potentially faster, Java has decades of refinement. And remember that Java appeared in 1995, it had to be usable on machines of that time. Electron is at the bottom end for many reasons; it uses JS, a dynamic language that will have a hard time beating static/native code despite all the work poured into it. It has a ridiculously large runtime (a full browser), and every app, no matter how small, has a copy of it. And remember that Java was used in some way in early phone apps, including the first Android devices, at that time phones were seriously underpowered compared to the quasi-desktop performance we not have.
  - laumars 5y ago
    Java was used long before Android. It was in feature phones, like from manufacturers like Sony Ericsson (and developers would write games and mapping software in it too).
    - tcoff91 5y ago
      SIM cards actually run a stripped down Java on them.
      - laumars 5y ago
        So do Blueray players, Java is everywhere.
      - pdkl95 5y ago
        A friend of mine had one of these (1998-99): https://electronics.howstuffworks.com/gadgets/home/digital-jewelry3.htm https://electronics.howstuffworks.com/gadgets/home/digital-j... > The Java Ring is a stainless-steel ring, 16-millimeters (0.6 inches) in diameter, that houses a 1-million-transistor processor, called an iButton. The ring has 134 KB of RAM, 32 KB of ROM, a real-time clock and a Java virtual machine A wearable device that could run arbitrary portable code was a cool idea.
    - KronisLV 5y ago
- mmphosis 5y ago
  Jazelle DBX (direct bytecode execution) https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
- capableweb 5y ago
  I know this is not a perfect benchmark, but TechEmpower runs benchmarks with tons of different libraries and frameworks, here is the latest round, filtered by just Java and JavaScript technologies: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune&l=zik0ov-sf https://www.techempower.com/benchmarks/#section=data-r18&hw=... First JavaScript on that list ranks 21th. If you check out the complete listing (all languages, https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r18&hw=...), then a Java program comes at 4th place, after two Rust programs and one C. Conclusion, Java is not as slow as people think, and absolutely faster than anything involving JS.
  - KronisLV 5y ago
    I had a discussion about benchmarks and how useful they are a few days ago: i remember mentioning TechEmpower in particular because of how close to typical real world usage of the libraries and ecosystems their benchmarks are! That said, Vert.X and some other of the frameworks aren't exactly idiomatic Java, because they're heavily focused on maximum performance - when i last checked them out, there were even async JDBC drivers in development, and while the performance was indeed stellar, it wasn't exactly production ready back then. Edit: well, the actual way it writes and reads isn't bad in of itself, but some might need some time to get adjusted to the concepts. Actually, i'd say that it reads a bit more like JS: https://vertx.io/docs/vertx-core/java/ https://vertx.io/docs/vertx-core/java/ Of course, things have probably improved, but perhaps it's also useful to compare some of the full platform implementations and perhaps the most popular of each language's frameworks. Maybe even with ORMs, to also see how those technologies fare in reality, since i've personally seen some of the most widely used enterprise frameworks become pretty slow due to all of the abstraction that's going on, which perhaps is a deserved criticism for Java. So for most of the "boring & stable" projects, it could look a bit like the following: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune&l=zik0ov-sf&o=e&f=2l24g-5pfk-27xgcw-0-0-72f4-4g-4-27xgcg-0-0-0 https://www.techempower.com/benchmarks/#section=data-r18&hw=... - Java, Spring: the most popular enterprise framework in my experience - Java, Dropwizard: a pretty good alternative to Spring that takes a number of the industry standard frameworks/libraries and integrates them (Quarkus not featured because while the MicroProfile compatibility would be useful to test, they actually have no tests with ORMs for now) - JavaScript, Express: still the most popular framework for back end development with Node - JavaScript, Node: sometimes i've seen people write servers directly as well, which is surprisingly far easier in Node than it is in Java (servlets and the abstractions around them can be unpleasant to work with) (Koa not featured because while it's gaining popularity, they actually have no tests with ORMs for now) With those particular frameworks, the scene changes a bit and both of them are far more similar in their performance. I'm not sure what the takeaway here would be: whether it's that Wirth's law (https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law) applies to libraries that try to cover all use cases, that Java just has some popular frameworks which underutilize its potential for performant code, or that you really should compare particular frameworks, paradigms and implementations, rather than just languages in general (since the overhead cannot be disregarded). Of course, these results also may not be representative of the stacks that other companies use or even those that are popular in other regions of the world, so i invite you all to check out those results for yourselves with the stacks that you're considering and maybe even browse the test source code: https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...
- jjice 5y ago
  If I had to wager a guess, getting to skip parsing at runtime, better typings known to the compiler, and having a lighter runtime all help. Having good type info is especially powerful for compiler optimizations, and a situation that JS get a lot less often than Java. I'm assuming the JVM is lighter overall than Node, but that's just a guess, and AOT(ish) probably helps as well.
- DonHopkins 5y ago
  The most awful problem with Java is that Larry Ellison owns it. So the real question is: "Ugh, Why Oracle?!"
tyingq 5y ago
Reminds me of DESQView. https://en.wikipedia.org/wiki/DESQview https://en.wikipedia.org/wiki/DESQview
- smhenderson 5y ago
  Indeed, the overview page even mentions that. XtermWM is expected to be helpful to the following kinds of people: Third item on the list is: People who used the DOS-era "shells" like IBM DOS Shell, DESQview... I can definitely see the appeal of this over a ssh link to a server you're trying to keep lean.
smusamashah 5y ago
This looks like VTM https://vtm.netxs.online/ https://vtm.netxs.online/ it can be tested online by doing ssh vtm@netxs.online
- dleslie 5y ago
  That looks incredible.
  - sprash 5y ago
    It also feels amazing with all the animation and kinetic scrolling. I just wonder where to get the "Apps" showcased in the ssh demo and the screenshot.
  - azinman2 5y ago
    No kidding. I’m really impressed with a full window management system in the terminal like that. The way it creates a spatial desktop and supports the mouse in such a way? The “translucent blur” effect! Incredible! Anyone actually use this to get real work done? And if so, why not just use a normal GUI?
    - vngzs 5y ago
      It's easier and more lightweight to configure an SSH session than X11 forwarding or remote desktops. So if you do all your real work on a server or desktop that you access remotely, these kind of tools can be helpful. That said, all I really need is tmux to do my work. I use a tiling window manager as my daily driver. Don't see any reason I'd adopt a floating WM in the terminal except that it looks cool.
dredmorbius 5y ago
A similar concept is available as TWIN: the Textmode WINdowing environment. This is mentioned at the bottom of the "See Also" list at TFA. https://github.com/cosmos72/twin/ https://github.com/cosmos72/twin/ Screenshots at the (presumably old?) Sourceforge page: https://sourceforge.net/projects/twin/ https://sourceforge.net/projects/twin/
anonymousiam 5y ago
The name is confusing. I initially thought it had something to do with one of these two existing "xterm" things: https://en.wikipedia.org/wiki/Xterm https://en.wikipedia.org/wiki/Xterm https://en.wikipedia.org/wiki/X_terminal https://en.wikipedia.org/wiki/X_terminal I see that it is a "Window manager", but not related to The X Window System: https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System It does however provide windows of Xterms (first link above) with good compatibility to the X version. Cool!
bitwize 5y ago
This is like something a kid would write, or someone new to programming. Like someone wondered, "I love tiling window managers, what if my xterm had a tiling window manager in it for all my text applications?" That story is even suggested by the name. So the author either is relatively new to programming, or they have a Buddhistic "eternal beginner" mindset. That may be the most charming thing about this piece of software. Note that I'm not trying to impugn the author's competence, but praising their mindset, which is that of someone who's discovered that programming a computer is a journey of infinite possibilities, and is unafraid of judgement of their choice of name, application, programming language, etc. because there is sheer joy in the act.
- a-dub 5y ago
  seems more like unix based fanfiction/retro-appreciation for early 90s era desqview. as such, the author is likely over 40. terminal based tiling window managers have been around for decades, the most popular ones are gnu screen and tmux.

104 points by 6581 5y ago

cpach 5y ago

Is Java really faster than Electron? I wouldn’t have guessed that, but if it’s true: Hey, cool!

Nux 5y ago
Java can be very fast indeed. It gets a bad press because many programs coded in it can be quite heavy and bloated.
- cpach 5y ago
  TBH I think this is the first time I’ve seen a TUI done in Java. (There might be more examples out there but I can’t come to think of any right now at least.)
  - laumars 5y ago
    A TUI is ostensibly just a command line application with an event loop and plenty of {ESC} characters being written to STDOUT. And I can assure you there are no shortage of Java applications that run headless.
  - tyingq 5y ago
    A couple of TUI libraries for Java: http://www.pitman.co.za/projects/charva/Screenshots.html http://www.pitman.co.za/projects/charva/Screenshots.html https://github.com/mabe02/lanterna https://github.com/mabe02/lanterna And, lower level, there's jCurses, which despite the name, also works on Windows: https://github.com/kba/jcurses https://github.com/kba/jcurses
    - tyingq 5y ago
      Apparently, the linked project also separated out their Java TUI into a separate project called Jexer. https://gitlab.com/klamonte/jexer https://gitlab.com/klamonte/jexer
laumars 5y ago
I’m surprised you’re surprised. Electron runs like a dog on modern systems while Java has been used in enterprise applications since the 90s. They’re not even in the same league. But then there isn’t much out there that even comes close to the performance overhead of Electron.
- wk_end 5y ago
  Nonsense. Electron is a memory hog and a disk space hog, but perf-wide V8 is incredible given what it has to work with. Definitely within spitting distance of Java.
  - laumars 5y ago
    Electron is more than just V8 and in fact most of the UI elements (since we are talking about UI usage here) fall outside of V8. But it’s also worth noting that JavaScript isn’t as close to Java as you claim. Not only do the benchmarks posted in this discuss but that argument to bed, but also the existence of WASM too (is JavaScript was really that good then there would be no need for WASM).
    - cxr 5y ago
      Electron "runs like a dog" because Electron development is what you get when you let the dominant culture associated with NPM-and-GitHub-driven consensus take over. It's a culture that not just tolerates bad development practices but outright encourages them while discouraging good ones. (Hell, the majority of Electron/NodeJS programs are written in a style that struggles against the language and the bindings exposed by the host environment.) If most Electron and NodeJS programmers wrote code the way that they'd be forced to write the same program in Java, or if they wrote code like the JS that was checked into the Mozilla source tree for Firefox's UI 15 years ago to run on sub-GHz machines (or that was powering Netscape's UI 5 years before that), then the impression that JS is "slow" relative to Java wouldn't exist. There is no shortage of abominable enterprise software of yesteryear written by mediocre Java programmers. It's just that their currentgen counterparts are mediocre programmers working with React/Electron/NodeJS instead.
xiaq 5y ago
Java programs are slow to start because of all the JVM overheads, but after that the performance is probably between 1x and 2x as slow as C (it depends a lot on the workload, of course). Java is definitely not a slow language in general, just has slow startup. The slow startup time is the reason why Java is considered high performance in "enterprise software", but has a reputation of being slow among developers, especially non-Java developers. "Enterprise software" is usually long-running server-side programs, so you barely care about the startup time. But if you're using Java programs as part of your development workflow you'll tend to start and restart them repeatedly and the startup time can get really annoying. Java's GUI libraries also tend to be not very well optimized, which further contributes to people's impression of Java's performance. In the case of this particular project, even though it's a terminal application, since it's a WM you'll likely start it once and leave it running for a pretty long time (as opposed to programs like "ls" which you run again and again), so this is in fact a good place to use Java. You can also use GraalVM to compile Java programs ahead of time these days, and get much faster startup.
- capableweb 5y ago
  > You can also use GraalVM to compile Java programs ahead of time these days, and get much faster startup. Just wanted to add a note that there is a tradeoff involved, as programs compiled with GraalVM will have worse performance compared to running directly with the JVM, but the startup speed will be faster. For CLIs, GraalVM is a god send. For long-running servers/daemons, JVM is still king.
  - pjmlp 5y ago
    For CLIs, AOT compilation has been available since around 2000 for those whose employers could afford commercial JDKs, or try their luck with gcj. Nowadays both OpenJDK and OpenJ9 offer free JIT caches with PGO data, GraalVM isn't the only free beer option.
    - capableweb 5y ago
      > AOT compilation has been available ... commercial JDKs, or try their luck with gcj > OpenJDK and OpenJ9 offer free JIT caches with PGO data As someone who never been exposed to either of those options, what kind of startup times do they offer compared to GraalVM? With GraalVM compiled Native Image I get same startup performance as any random Go program, would those offer the same performance when it comes to startup? Is there any tradeoff regarding long-term performance for daemons and similar?
yung_steezy 5y ago
I believe Java web frameworks still come out on top in terms of performance speed.
- bitwize 5y ago
  C++ and Rust frameworks are faster. But Java is in like the top 3 or 4.
- laumars 5y ago
  Near the top. They never came out on top because languages like C++ would out perform (and now we have Rust too). But Java is certainly up there. That said, recently even a lot of the other languages have made some huge optimisations in the web server space too and so Java doesn’t even dominate amongst the byte code languages like it used it https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ That all said, comparing Java to Electron is like comparing a sports car to a camper van.
GuB-42 5y ago
In the hierarchy of performance, Java is what comes just after native C++, it may even be faster than Rust because while Rust is potentially faster, Java has decades of refinement. And remember that Java appeared in 1995, it had to be usable on machines of that time. Electron is at the bottom end for many reasons; it uses JS, a dynamic language that will have a hard time beating static/native code despite all the work poured into it. It has a ridiculously large runtime (a full browser), and every app, no matter how small, has a copy of it. And remember that Java was used in some way in early phone apps, including the first Android devices, at that time phones were seriously underpowered compared to the quasi-desktop performance we not have.
- laumars 5y ago
  Java was used long before Android. It was in feature phones, like from manufacturers like Sony Ericsson (and developers would write games and mapping software in it too).
  - tcoff91 5y ago
    SIM cards actually run a stripped down Java on them.
    - laumars 5y ago
      So do Blueray players, Java is everywhere.
    - pdkl95 5y ago
      A friend of mine had one of these (1998-99): https://electronics.howstuffworks.com/gadgets/home/digital-jewelry3.htm https://electronics.howstuffworks.com/gadgets/home/digital-j... > The Java Ring is a stainless-steel ring, 16-millimeters (0.6 inches) in diameter, that houses a 1-million-transistor processor, called an iButton. The ring has 134 KB of RAM, 32 KB of ROM, a real-time clock and a Java virtual machine A wearable device that could run arbitrary portable code was a cool idea.
  - KronisLV 5y ago
mmphosis 5y ago
Jazelle DBX (direct bytecode execution) https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
capableweb 5y ago
I know this is not a perfect benchmark, but TechEmpower runs benchmarks with tons of different libraries and frameworks, here is the latest round, filtered by just Java and JavaScript technologies: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune&l=zik0ov-sf https://www.techempower.com/benchmarks/#section=data-r18&hw=... First JavaScript on that list ranks 21th. If you check out the complete listing (all languages, https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r18&hw=...), then a Java program comes at 4th place, after two Rust programs and one C. Conclusion, Java is not as slow as people think, and absolutely faster than anything involving JS.
- KronisLV 5y ago
  I had a discussion about benchmarks and how useful they are a few days ago: i remember mentioning TechEmpower in particular because of how close to typical real world usage of the libraries and ecosystems their benchmarks are! That said, Vert.X and some other of the frameworks aren't exactly idiomatic Java, because they're heavily focused on maximum performance - when i last checked them out, there were even async JDBC drivers in development, and while the performance was indeed stellar, it wasn't exactly production ready back then. Edit: well, the actual way it writes and reads isn't bad in of itself, but some might need some time to get adjusted to the concepts. Actually, i'd say that it reads a bit more like JS: https://vertx.io/docs/vertx-core/java/ https://vertx.io/docs/vertx-core/java/ Of course, things have probably improved, but perhaps it's also useful to compare some of the full platform implementations and perhaps the most popular of each language's frameworks. Maybe even with ORMs, to also see how those technologies fare in reality, since i've personally seen some of the most widely used enterprise frameworks become pretty slow due to all of the abstraction that's going on, which perhaps is a deserved criticism for Java. So for most of the "boring & stable" projects, it could look a bit like the following: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune&l=zik0ov-sf&o=e&f=2l24g-5pfk-27xgcw-0-0-72f4-4g-4-27xgcg-0-0-0 https://www.techempower.com/benchmarks/#section=data-r18&hw=... - Java, Spring: the most popular enterprise framework in my experience - Java, Dropwizard: a pretty good alternative to Spring that takes a number of the industry standard frameworks/libraries and integrates them (Quarkus not featured because while the MicroProfile compatibility would be useful to test, they actually have no tests with ORMs for now) - JavaScript, Express: still the most popular framework for back end development with Node - JavaScript, Node: sometimes i've seen people write servers directly as well, which is surprisingly far easier in Node than it is in Java (servlets and the abstractions around them can be unpleasant to work with) (Koa not featured because while it's gaining popularity, they actually have no tests with ORMs for now) With those particular frameworks, the scene changes a bit and both of them are far more similar in their performance. I'm not sure what the takeaway here would be: whether it's that Wirth's law (https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law) applies to libraries that try to cover all use cases, that Java just has some popular frameworks which underutilize its potential for performant code, or that you really should compare particular frameworks, paradigms and implementations, rather than just languages in general (since the overhead cannot be disregarded). Of course, these results also may not be representative of the stacks that other companies use or even those that are popular in other regions of the world, so i invite you all to check out those results for yourselves with the stacks that you're considering and maybe even browse the test source code: https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...
jjice 5y ago
If I had to wager a guess, getting to skip parsing at runtime, better typings known to the compiler, and having a lighter runtime all help. Having good type info is especially powerful for compiler optimizations, and a situation that JS get a lot less often than Java. I'm assuming the JVM is lighter overall than Node, but that's just a guess, and AOT(ish) probably helps as well.
DonHopkins 5y ago
The most awful problem with Java is that Larry Ellison owns it. So the real question is: "Ugh, Why Oracle?!"

tyingq 5y ago

Reminds me of DESQView. https://en.wikipedia.org/wiki/DESQview https://en.wikipedia.org/wiki/DESQview

smhenderson 5y ago
Indeed, the overview page even mentions that. XtermWM is expected to be helpful to the following kinds of people: Third item on the list is: People who used the DOS-era "shells" like IBM DOS Shell, DESQview... I can definitely see the appeal of this over a ssh link to a server you're trying to keep lean.

smusamashah 5y ago

This looks like VTM https://vtm.netxs.online/ https://vtm.netxs.online/ it can be tested online by doing ssh vtm@netxs.online

dleslie 5y ago
That looks incredible.
- sprash 5y ago
  It also feels amazing with all the animation and kinetic scrolling. I just wonder where to get the "Apps" showcased in the ssh demo and the screenshot.
- azinman2 5y ago
  No kidding. I’m really impressed with a full window management system in the terminal like that. The way it creates a spatial desktop and supports the mouse in such a way? The “translucent blur” effect! Incredible! Anyone actually use this to get real work done? And if so, why not just use a normal GUI?
  - vngzs 5y ago
    It's easier and more lightweight to configure an SSH session than X11 forwarding or remote desktops. So if you do all your real work on a server or desktop that you access remotely, these kind of tools can be helpful. That said, all I really need is tmux to do my work. I use a tiling window manager as my daily driver. Don't see any reason I'd adopt a floating WM in the terminal except that it looks cool.

dredmorbius 5y ago

A similar concept is available as TWIN: the Textmode WINdowing environment. This is mentioned at the bottom of the "See Also" list at TFA. https://github.com/cosmos72/twin/ https://github.com/cosmos72/twin/ Screenshots at the (presumably old?) Sourceforge page: https://sourceforge.net/projects/twin/ https://sourceforge.net/projects/twin/

anonymousiam 5y ago

The name is confusing. I initially thought it had something to do with one of these two existing "xterm" things: https://en.wikipedia.org/wiki/Xterm https://en.wikipedia.org/wiki/Xterm https://en.wikipedia.org/wiki/X_terminal https://en.wikipedia.org/wiki/X_terminal I see that it is a "Window manager", but not related to The X Window System: https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System It does however provide windows of Xterms (first link above) with good compatibility to the X version. Cool!

bitwize 5y ago

This is like something a kid would write, or someone new to programming. Like someone wondered, "I love tiling window managers, what if my xterm had a tiling window manager in it for all my text applications?" That story is even suggested by the name. So the author either is relatively new to programming, or they have a Buddhistic "eternal beginner" mindset. That may be the most charming thing about this piece of software. Note that I'm not trying to impugn the author's competence, but praising their mindset, which is that of someone who's discovered that programming a computer is a journey of infinite possibilities, and is unafraid of judgement of their choice of name, application, programming language, etc. because there is sheer joy in the act.

a-dub 5y ago
seems more like unix based fanfiction/retro-appreciation for early 90s era desqview. as such, the author is likely over 40. terminal based tiling window managers have been around for decades, the most popular ones are gnu screen and tmux.