search

HyDE-Project / Hyde-cli

A HyDE CLI, wrapper, tweaks , workarounds, and more!
https://github.com/prasanthrangan/hyprdots
GNU General Public License v3.0
107 stars 9 forks source link

Suggestion: Move to Rust or Go for more advanced features #54

Open imide opened 5 months ago

imide commented 5 months ago

I think the project is a really good idea! I would like to contribute, but I do not know shell (and not really interested in it as it looks like a hernia).

I think migrating/porting this project to another language with incredible TUI/GUI potential (go which I prefer or rust) would benefit the project greatly.

just a thought!

kRHYME7 commented 5 months ago

😂 At last someone opened an issue about it.

The mindset for this CLI is to have lesser or no dependencies at all. This way it is lightweight, no need to be compiled etc.(yes we can package binaries, but I don't think I gained enough trust yet.)

However, it is true that we need to migrate to a lower level for optimization plus more capabilities. Especially if planning to use some toolkit for GUI, Daemon and excessive text manipulation.

I am planning to make a submodule for this CLI, It should be 'Hyde-shell' , initially a welcome app, but it's in CPP. My experience for cpp is barely enough for robotics and automation, and I suck!

Therefore, I'm planning to try a fresh start of rust soon if some features are needed.

So for the CLI, would it be fair if we stick to Shell for now? It's lightweight and easier to deal with.

At the time, I'm planning to find/write a parser that we can use for hyprland configuration, it would be useful in the long run. Issues are Hyprlang do not have bindings yet for other languages. We can read the active hyprland vars though.

Sorry for the long reply 😁

imide commented 5 months ago

no problem! would rather have a long reply than a lgtm lmao I understand! whatever you feel comfortable with, this is your project after all! upon better support for config parsers and irc stuff, we can revisit this!

Oskar-Idland commented 5 months ago

I believe Go/Python would be the best lang for the job. Rust/C++ would be a bit overkill.

Python also yields as fast of a development cycle as bash would anyway, so I do not think the shift over would be that hard. We could make another branch, where we tried to port every script over gradually, and see where it goes? Would love to help.

imide commented 5 months ago

I believe Go/Python would be the best lang for the job. Rust/C++ would be a bit overkill.

  • Packaging binaries would be ok, as long as the source code is open.
  • Go has a simple syntax, and a TUI community already like bubbletea.
  • Python is popular for larger scripts with more logic, even simpler syntax, and is fast enough for the task we are doing here. Python will also most likely have the largest pool of users that can help code, as if you know C++, python is easy, but not vice versa. It is also an interpreted language so it is easy to debug at run-time (which hyde often demands), making it easier to fix bugs for the user as they do not need to compile, just run.

Python also yields as fast of a development cycle as bash would anyway, so I do not think the shift over would be that hard. We could make another branch, where we tried to port every script over gradually, and see where it goes? Would love to help.

I agree on the branch part. However, I only know/comfortable with Go and willing to learn Rust. Python doesn't really make sense for a CLI/TUI program. (also handling python fucking blows)

kRHYME7 commented 5 months ago

All points are valid here. However, IMO, the easiest way to 'deliver' the CLI into to everyone's doorstep is to use bash as the main interface/laying ground. This might not be the convention(some distro is doing this actually), but this is the only lightweight most way I could think of. For things like TUI, we can move forward to something TUI-friendly soon.

We can pick some functions here that requires a rewrite or seen to be better optimized. And absolutely, we can add another feature. image

As you can see, the CLI is not doing a very specific thing, it acts as a wrapper to everything HyDE related. For now, I can't see a rewrite for the main layer, as function calls are just fine and well integrated with Linux even at vanilla installation.

image

So this is just a bash function calls, so let me know if you got some features in mind, will definitely talk about integrating it. image

rubiin commented 5 months ago

Shell scripts just work in most unix systems without needing to add anything extra. Also since we are not doing anything cpu intensive , I dont see any performance gains using rust for the core scripts . If its for the aesthetics , then yes perhaps adding a tui layer is another option which can be made in any language.

TUI can serve as a lazy way of using the scripts without needing to write cli commands manually. For example, LazyGit is the tui version of git which complements it well

rubiin commented 5 months ago

https://www.youtube.com/watch?v=jw5J0rhLQyA&t=322s inspiration for TUI

Radrahil commented 5 months ago

I think this should be a discussion, and yes, please do this. Hyde is currently the single worst part of Hyprdots (No offense) and it's also kinda hard to give bug reports because you often have to find out yourself what went wrong, and it doesn't throw errors seemingly at all.

kRHYME7 commented 5 months ago

and it doesn't throw errors seemingly at all.

It tries to, and you missed it 😉 also, please change your branch to main. My bad making you stuck in the hyde branch. You need to change back to main. And hope the updates won't be too rough from now on.🤞

Hyde branch