Low level rewrite

[porky11]

Perceived idea awesomeness

• Wow, you don't have this yet???
• Would be super cool.
• I'm not sure a lot of people would use it, but I'd love to have it.
• Kind of a gadget, honestly, but why not?

Perceived idea difficulty

• Quit your job first.
• Would need some work, but nothing impossible.
• Shouldn't be too hard to make.
• Like, I could do it.

---

Rewrite this in a lower level language like C (or Rust). This should be more efficient. Interactive stuff in eDEX runs pretty slow.

Maybe some idea for an alternative project.
It's probably best to fork a simple existing terminal emulator like xterm, st, alacritty, etc. and add features like in eDEX.

I think, the inbuilt file manager of eDEX is a pretty nice feature, which is very intuitive, but I didn't find an existing terminal emulator, which does this in a similar way.
I started to dislike file managers, but being able to select files and then just enter them as arguments automatically is very cool. It combines the positive aspects of both, file managers and terminal emulators.

I should probably try this myself, when I'm in the mood. But I wanted to share this anyway.

[Benimautner]

Although this would be cool, I cannot imagine that it is something that is easily done as writing complicated UIs in low-level languages is generally harder and you could not easily just "copy-paste" the code and adapt it a bit. This would require a FULL rewrite.

This is just my opinion by the way.

See also this pinned issue by the creator: #769

[porky11]

I already read the pinned issue, but I fear, it's not meant to be rewritten in low level languages.
The main problem is not the language, but the need/conversion of the HTML/CSS stuff.

[GitSquared]

Interactive stuff in eDEX runs pretty slow.

I want to start by saying this is not a universal truth. On most computers sold after ~2018, it runs just fine - I've seen 60+ FPS on what was originally a Chromebook.

At release, it ran like shit, because the code itself is not really a marvel of engineering, but I've patched in some optimizations since (notably, eDEX is very good at scaling to multiple threads/cores). But I digress.

Rewrite this in a lower level language like C (or Rust). This should be more efficient.

Define efficiency. Is efficiency putting less stress on hardware resources and rendering more frames a second? Then yes, probably, it could be hugely more efficient. But we're not talking about some server-side enterprise software, we're talking about a UI experiment.

So what's efficiency for a UI experiment? It's at what speed you code in new features. It's how fast you get those features in front of people. And let's not forget everyone uses different platforms - good luck distributing a multi-platform GUI Rust desktop app.

The idea of eDEX-UI did not magically pop up in my mind. The name is actually a combination of "e" for Electron, and DEX-UI, the original project - which really should tell you just how creative I am.

DEX-UI was actually written in C++/C with OpenFrameworks. So does it perform better? Well I can't tell you because it's been 4 years and I still haven't figured out how to install it. And I'm not alone, hence why it didn't spread as much as this one did. Sorry, Seena.

I think, the inbuilt file manager of eDEX is a pretty nice feature, which is very intuitive, but I didn't find an existing terminal emulator, which does this in a similar way.
I started to dislike file managers, but being able to select files and then just enter them as arguments automatically is very cool. It combines the positive aspects of both, file managers and terminal emulators.

I'm very glad to read that!

So, let's recap: I packaged some interesting UI concepts, some new, some old, in a experimental app.
It catched on nicely because it was visually interesting, until it reached you, who also found it interesting and decided to try it out.
It worked on your machine, and you liked one of those UI ideas so much that you ended up using it for more than a few minutes.
And now you're considering implementing it in "real", non-experimental, software.

How efficient is that? 😉

Sorry for the whole write-up, but you're not the first one to talk about this and now I'll have a comment to link to whenever that pops up again.
In the end, this is open-source software, so do what you want, but keep in mind optimal performance shouldn't be a goal until your ideas are sufficiently refined, and eDEX's ones definitely aren't.

[gbonnema]

Thank you for explaining this stuff. I really don't like js (prejudice, I know), but your rant puts it pretty much into perspective. As a user, I would say gime, gime, gime! Of course as ex cobol, C, Rust programmer ..... As I am mostly user now, I really would like to check out the app. The only reason I am hesitant is because Fedora has not yet incorporated it into their repository. But I certainly will check out the code. Once I trust it, I suspect it is awesome (yeah, I saw a review on youtube). Thank you very much for your effort of maintaining and expanding on the code!

[porky11]

I want to start by saying this is not a universal truth. On most computers sold after ~2018, it runs just fine - I've seen 60+ FPS on what was originally a Chromebook.

My PC is already a few years old, but I used powerful hardware back then.
The CPU I use: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz

Most things work well, it's just about terminals with many refrehs per second.

Define efficiency.

Just compare cmatrix on a regular terminal and eDEX. For sure, it's not as efficient as an optimized terminal.

But we're not talking about some server-side enterprise software, we're talking about a UI experiment.

Right, and it would be nice to see this stuff not only in an experiment.

And let's not forget everyone uses different platforms - good luck distributing a multi-platform GUI Rust desktop app.

That's not difficult. Some time ago I wrote some graphical rust program, which I tested on multiple systems:

• different versions of Linux: x86_64 (glibc and musl), AARCH64 (rpi4)
• Windows 10

the original project
Nice, I didn't see this yet. But eDEX looks much better.

DEX-UI was actually written in C++/C with OpenFrameworks. So does it perform better? Well I can't tell you because it's been 4 years and I still haven't figured out how to install it. And I'm not alone, hence why it didn't spread as much as this one did. Sorry, Seena.

I also just tried it. It's not a language problem. There is no documentation, no binaries, no standard format, you would use for installation (Makefile, cmake, autogen, etc.), and if I try to compile it like a typical C++ project, it just fails because some included files do not exist.

How efficient is that?

I would rather call this effective. But looks like you reached the goal you wanted to reach :)

[tomByrer]

This code is already multi-threaded, & the one suggestion I was going to make, upgrade to the latest Electron (for the newest fastest Chrome V8) @GitSquared already completed around the time of your last reply. Maybe do a rebuild from source & see if that is a bit faster for you?

Otherwise, sounds like you have a project for this winter @porky11 ;)

I wrote some graphical rust program