Feature Requests!
Closed this issue · 47 comments
Have an idea for a command or feature for the JTerm application? Comment below! 😄
I'm looking to get a bunch of ideas for new things to add, and stuff I'm possibly overlooking that should have been added already. So, if you ever think of something, comment, and we'll discuss the possibility of adding it to JTerm! 😀
Would you not want to start off by implementing the same functionality as a standard cmd console, for example? Also, I downloaded the latest version of the program on Linux and it crashed as soon as I entered a command, so I might jump on and give you a hand with some code.
The issues I had were due to a faulty Java setup, everything runs fine now.
In terms of features, there are a lot that we can add, but any particular direction or subset you would like to tackle? All you really need to do at this point for inspiration is type help in your terminal window, take notes on which commands you want to implement and then implement them :P
An interesting idea would be the tab completion for example, completing commands and file/folder names. Also, perhaps having the commands run by dir be independent, having to type dir cd or dir ls is a bit confusing and redundant... Being able to execute programs from the terminal too, not only bash scripts...
I'll get to work on some commands myself in a couple days, I'm still trying to understand your code and formatting. Also might want to reconsider your layout, as the project grows larger you will have an ungodly amount of Java files sitting in the same folder, might be a good idea to split them into categories or something like that.
TL;DR The possibilities are limitless!
Well, as of right now, the main thing attempting to be worked on is Batch File Interpretation (#7).
Actually, back in around 0.2.0 of the project, I attempted to get tab completion working but ended up giving up on it, so if you have any knowledge around this or have an idea for its implementation, I'm taking all the help I can get. 😜
As for the whole dir ls, that was actually just implemented into the project. Before it was only the ls command, but with the new way of calling commands that was the only solution I saw at the time. If you want further details on this, you can look in the JTerm.Parse function for its implementation.
Executing binaries might not be that hard either, and should be non-OS-dependent, so I'll research this and see what I can find.
As for separate folders, I actually did have the same thought go through my head while I was implementing the new command parser, but never followed up on it. 😋 I'll look into this as well. (Hopefully Maven won't have any issues with it.)
Thanks again for your help so far! If you have any questions, don't hesitate to ask. 😄
In regards to the dir ls thing, a hashmap could be implemented where all the functions are mapped to their file, so when you enter ls, it looks it up in the hashmap, returns dir and adds ls after it to run it. The downside to that is that each command would have to be hardcoded.
I looked into tab completion, and it looks either impossible or very challenging, especially without the use of a 3rd party lib. I tried a million things and none worked, so anyways... Might do some more on that tomorrow.
As for running binaries, using the standard runtime and process method should work, with a couple modifications depending on the OS maybe, since in Linux programs are called with ./ before the name for example. I might work on that tomorrow if I decide to give up on tab completion.
I'll start opening new issues for the different topics if you don't mind, so that we don't flood this one thread
Sounds good 👍
Should probably add a couple more issues with additions that you want to make so people can just choose stuff and go for it, if they find the topic interesting or have ideas as to how to approach it. If you can think of anything, add it, since all I am currently doing is running help in my linux terminal and looking at what seems reasonable and essential at this point.
Also, what is the plan to get to 1.0?
Sounds great! 😁
(Also nice profile pic 😛 )
Also, what is the plan to get to 1.0?
It would be cool to kind of map out the necessary items that should be finished before getting to 1.0.
We could even create a 1.0 milestone and tag issues with it.
@ccmetz Hm, good question. I'll attempt to write up a roadmap docfile tomorrow, and I'll probably put it in a Wiki page. And I suppose we could also use a milestone to track.
@ccmetz The ROADMAP.md file is up in the dev branch! Also, the "v1.0.0 Roadmap" is now used for tracking Issues. https://github.com/Sergix/JTerm/blob/dev/ROADMAP.md
Might be neat to add a Java GUI text/file editor. Might be a little ambitious, but I thought it'd be a cool idea.
I suppose it's plausible, although it would be really neat to have a terminal text editor similar to Vim or nano.
And a Text Editor GUI would probably be relatively easy. :P
I do prefer a terminal editor yeah. I just thought that'd be a little harder
Yeah it's a lot harder :P
If you or @nanoandrew4 or @ccmetz want to give it a shot, or we probably could just all work together on it, then let me know!
I have literally never tried GUIs in java before, but I'll do some research
@NCSGeek If you can avoid GUI's, avoid them. #1 source of bugs I find, plus they're a pain. Also, this is a terminal, so I think a terminal editor would be more appropriate. As to how to approach it, probably either open a "new" terminal window in which to type in all the stuff, and then save it to a text file, or save all input, clear screen and use that window for editor, and reprint all the commands once the text editor is closed.
Just some ideas!
Thinking over your comment, It's true that we should probably stick to terminal style since that's what we already have, now It seems obvious. So yeah, I agree now that I've thought it through
Yeah, Java GUIs are extremely annoying layout-wise as well.
As for the opening a new window, that's actually a task on the Roadmap, so it's possible we could proverbially kill two birds with one stone with this one.
If someone wants to open up a seperste issue(s) then that would be great. :)
I will work on binaries execution tomorrow and then open that, if no one has taken care of it. Would be kinda interesting to tackle to be honest. I'll start messing with it some time soon, it's not going to be easy.
Just a quick question on the roadmap, we are going from v0.5 to v1.0 directly?
No, actually I'm about to push v0.6.
But yes, once the roadmap is complete we'll go to v1.0.
And don't you think maybe we should be aiming to include more in v1.0? Right now we have a very basic command line, I think v1.0 should be put off until we have a more functional piece of software.
Also, might want to check out semantic versioning! I just recently read about it, and it helps keep the version numbers reasonable while providing indication of what kind of changes take place from one version to another. Just a thought.
Well, if you have any ideas, then sure. :P But that's what I thought we would need to get a basic but functioning terminal.
And if you check CONTRIBUTING.md, we are already using semantic versioning.
Should have checked before saying that, and it's even present in the main class for the project! My bad. As for ideas, I will open an issue for the text editor, and there are some other things that should be taken care of fix wise. As for ideas, just look at a normal terminal and see what kind of functionality you expect out of it, that's the best source of inspiration right now.
@Sergix As Hacktober fest is going on, if you throw some Hacktoberfest tags on the issues we might get some people on other issues, since if they get enough pull requests, they get a T-shirt :D so win win for all.
@nanoandrew4 True! Thanks for the suggestion. 😄
Also, I greatly apologize for my lack of presence and work on this project lately. Again, I have had nearly no time at all lately to work on coding with school and sports. (@NCSGeek can vouch for me on this. 😛 ) Especially with the great work you have done so far in helping on this project, I feel very bad that I haven't kept up with maintenance and basic tasks. Hopefully you understand. 🙂
I get it, I'm in the middle of midterms and as you can see my efforts have been lacking too. I will hopefully be back on it in a couple of weeks, if things settle down again. In the meantime, whenever you have a moment, I fixed the PR so that only good code is in, so it is ready to merge.
Good luck and see you around!
Glad to see someone else is in the same boat as me. (Or does that sound detrimental? 😜 )
Anyways, with the amount of bug reports we have at the moment, and with the possibility of the count increasing, do you think it would be a decent idea to create a "Bug" milestone?
Since I've never hosted a public repository in which people participated I'm not sure what the purpose is, but if you think it'll help, by all means. Also might want to add outstanding issues to the 1.0.0 milestone, since we're not even at 0.6 yet xD
I'm planning on going ahead and merging to 0.6.0 tonight. It's been far too long since a version release. 😅
Does the idea of integrating our own text editor still sound feasible? I am almost done with issue #47, so I can get rolling on that soon.
Right... I have to fix that for a good editing experience... sigh
Hello there guys,
I found your project on up-for-grabs. I would like to suggest you guys some different approach for the command execution. I took a look at the latest version of the project and you were using reflection with annotations in order to execute the commands. The problem I see about this is the reflection, as it's very neat and I as well quite like it and all, but not that efficient.
So my suggestion is to approach this with a super class, all the commands would extend from. Could be an abstract class to make the commands classes overwrite the method/s proposed in the super class.
The parameters and the amount of it could easily be handled in the method that is executed from the command class. The only problem about this I can think of is the memory the JVM has to allocate for the instances which would need to be saved in the HashMap with the keys. It shouldn't be too much of a problem, as the instances shouldn't be that big.
Nevertheless I see more efficiency in the use of a super class and the invocation of a method that every command has, like e.g. an execute() method.
If you guys like the idea, I would like to do a pull request in order to help you. I am just not that experienced with pull requests. Probably someone should explain to me how it's done the best way :D
Hello, @DataSecs! Thanks for you interest in our project. 😄
I have read your proposal, and I think it's a sound idea. I actually had the same concerns as to memory usage. If you could, could you open a new issue and write a small snippet that demonstrates the basis of your suggestion?
Thanks!
@Sergix
Of course, no need to thank ^^
That's a nice idea. I will get right into it 👍
PS.: I just noticed you are already putting instances of the Executor in a HashMap, which probably should be bigger than my suggested Command instances. So probably this could be a better approach for memory saving
@DataSecs Sounds great! If you haven't already, I would create a fork of this repository for future use, and so I can refer to it when you have changes made at some point.
Hello there!
I found out about the project on up-for-grabs today. I've been reading the source code and I'm interested in contributing. I was thinking about implementing a find command to check if a certain file or directory exists within the working directory.
I imagined a syntax like "find [-h] [-r] name [directoryToSearch]" (where the "-r" option would make it recursive and include checking subdirectories and adding the optional directory to search would make it look in there instead of the working directory) and using the methods of the apache commons FileUtils class for the search, which I saw has already been used in the project.
If you guys like the idea, I'll open and issue and start working on it right away!
Hey there, @PabloPaglilla!
Thanks for your interest in our project!
I definitely like the sound of that idea. I actually never thought about including that feature, so thanks for the proposal!
You can go ahead and open the issue. Just make sure you (1) work off of the dev branch, (2) use the command class syntax (if you have any questions on this, feel free to ask!) and (3) track your commits in the issue by adding the #(issue number) in your commit messages.
Good luck, and of course, don’t hesitate to ask any questions you might have while you are working on it. Thanks!
Great!
I'll open the issue and start working on it right away.
This is actually my first contribution to an open source project, so thanks for the help! I'll ask if I need anything.