The idea about the terminal implementation is that on any computer (Windows, Linux, Linux server edition, Unix,…) the application can be ran the old-skool way, using command line aka terminals. The ideas explained on this page are only conceptual ideas so far. Implentation hasn't started yet on this topic and even if it was those conceptual ideas stay conceptual.

The application can be started from commandline with some parameter, eg JDownloader -guiless. JD gets control over the entire terminal to use every line that is visible to the user to display continuous status information. This information gets updated every x miliseconds.

A second way to start JD is to use some kind of ghost option (JDownloader -ghost). This way the application is started from the command line but no graphical interface is shown nor a terminal interface. Altough the application can still be controlled as described in the „Controlling JD” part beneath.

Logging should not be done in the terminal but all loging should just be written to a file. For the output in terminal window system.out.println or something simular can be used! To change the logging it's good have a look at the JDLogger.getLogger() method. First opinion on this is that the JDLogger class should be extended to use a TerminalLogger and FileLogger or something like that. When JD is started in terminal mode, only the FileLogger will be used. When JD is started in normal GUI mode both loggers are used (console.setLevel(Level.ALL); would become console.setLevel(Level.OFF);).

One or more watchfolders can be defined in which container files can be dropped and automatically picked up by JD. The handling of the container files is already present, the watchfolder functionallity is probably still to be implemented.

The running instance of JD can be controlled using a second terminal window in which pre-defined commands can be entered using the same executable as used to start the application. Eg:

• JDownloader -pause
• JDownloader -continue
• JDownloader -stop
• JDownloader -start
• JDownloader -update
• JDownloader -speed
• JDownloader -maxcon <maxNumConn>
• JDownloader -speed <speed>
• JDownloader -maxDls <maxDls>
• JDownloader -addwatch <folderLocation>
• JDownloader -remwatch <folderLocation>
• JDownloader -add <link>
• JDownloader -remove <packageName>
• JDownloader -order <packageName> <newPosistionInQueue>
• JDownloader -queueFirst <packageName>
• JDownloader -queueLast <packageName>
• JDownloader -force <packageName>
• JDownloader -quit
• …

Other options such as some kind of reporting can also be integrated here. For instance:

• JDownloader -status queue
• JDownloader -status downloads
• JDownloader -status all
• JDownloader -status watchfolder

According to coalado the „start binary and pass parameter to running instance” thingy already works. So nog big deal on this one. It should only be extended with more parameters to be used! This will probably be at least 20 parameters.

JD has a lot of configuration options and we do not want the user to mess around in configuration files etc so an entire terminal configuration interface will be implemented. This interface can be started with the command JDownloader -config. All non-gui related options of JD will be available through this interface so the user can easily edit the values of it.

For this gui-less implementation no internationalization will be implemented at first. If needed internationalization can always be done afterwards!