App roadmap

[USLTD]

@o-sdn-o mentioned that he was planning to make vtm come with only few built-in widgets (apps) while others would be standalone and could be compiled separately. I am making list of what apps should be built-in by other DE "standards" (There is no standard but this is so far most popular configuration)

This list is unofficial, meaning that it doesn't mean that these "apps" will definitely be implemented and based on developer's response I will update list

• Terminal Emulator
• File Manager and Browser
• Web Browser
• Settings
• Window Manager / Tiles
• App/Widget Manager w/ "Installer"
• Notifications (like nvim-notify)
• Download Manager [OPTIONAL]
• Archive Extractor and Archiver [OPTIONAL]
• "Registry Editor"
• Office Applications like Spreadsheet, Wordpad, Slides and more [OPTIONAL]

Suggestions from @AutumnMeowMeow:

• Color theme editor [OPTIONAL]
• Connection manager (if supporting shared sessions - maybe already here?) [OPTIONAL]
• Character/emoji map/browser/picker (in another words UnicodePad) [OPTIONAL]
• Built-in simple text editor (already here?) - for sticky notes and quick text files [OPTIONAL]
• Screen shapshot tool (Screenshoter or Screen Capturer) [OPTIONAL]

Suggestions from @tomek-szczesny:

• Image viewer
• Volume Control System [OPTIONAL]
• Audio Player [OPTIONAL]

[AutumnMeowMeow]

What's the distinction between "Settings" and "Registry Editor"?

Some other things -- everything optional of course:

• Color theme editor
• Connection manager (if supporting shared sessions - maybe already here?)
• Character/emoji map / browser / picker
• Built-in simple text editor (already here?) - for sticky notes and quick text files
• Screen shapshot tool

[o-sdn-o]

There is also such a list of planned applications in the imaginary Desktopio store on the demo server 🙂

[USLTD]

What are those stars? And numbers?

[o-sdn-o]

This is all fictional information for fun.

[USLTD]

What's the distinction between "Settings" and "Registry Editor"?

Some other things -- everything optional of course:

• Color theme editor
• Connection manager (if supporting shared sessions - maybe already here?)
• Character/emoji map / browser / picker
• Built-in simple text editor (already here?) - for sticky notes and quick text files
• Screen shapshot tool

In my idea settings allow graphically modify some "public"/"high-level" settings (window style, keybinds and wallpaper) while "registry" allows user to modify "low-level" settings.

[tomek-szczesny]

The web browser would be really tricky to implement. browsh does a fantastic job at rendering websites in text mode (using firefox as its backend), but the usage is super awkward and I never bothered learning their keyboard shortcuts. Something like that, but with tabs and address bar like all the modern browsers do would be fantastic. But I know I'm asking for a lot here. browsh also has notorious problems with killing firefox after it exits.

vtm settings applet is of course welcome, and I'd keep it unified rather than broken down into many "apps". It could have a "advanced" checkbox for hiding advanced settings, but preferably everything should be available in one place. Color theme editor should also be accessible from within settings app. Don't you just hate when settings are scattered randomly in multiple applets?

Screen shapshot tool

That would be awesome, especially if a user could select a snapshot region with a mouse, like "snipping tool". I'm not sure what is the anticipated output though - raw text, text with VT100 gibberish, or a bash script that ensures proper display of the screenshot?

I'd add to the list:

• Image viewer (like classic IrfanView)
• Volume control (could be based on alsamixer / pulsemixer)
• Music player (a simple wrapper for mpv, maybe? I use mpv in No-X environment, it handles ALSA without pulseaudio very well)

[Vosjedev]

I am interested in making some of the applications in the checklist, mosly interested in the filemanager. I am also thinking about the application 'store'/manager.

I would like to add a panel with stuff like battery, time, (maybe wifi), username, etc. I am thinking about making that first (by just echoing info to the bottom line of the screen with some color (I know, there are better ways, like implementing it directly in vtm.))

The reason I have not started yet is because of scripting. It would be nice to start a window from a python script (using os.system() is an option).

I will update here if i made something, and link the repo. (I think i will give a link to a first version of a panel this weekend)

edit:
forgot to say: my applications will be cross-platform, but I cant test on windows (no windows machines : D )

edit 2:
I dont know if the panel will be cross-platform, it depends on if I can get info via a python3 module that work cross-platform. But i think the only people needing a panel with such info are running a unix-like terminal-only environment. (Correct me if windows without gui still exists : D )

[Vosjedev]

Following my last post:
Some settings for default apps in the config would be nice, so the filemanager knows which app to use for which type of file. This is where the option to script opening windows comes in: the filemanager can then open a new window with the correct application running

[o-sdn-o]

The reason I have not started yet is because of scripting. It would be nice to start a window from a python script (using os.system() is an option).

You are absolutely right.

Widgets and applications for vtm can be created already now, but in C ++, and this is very laborious. Without integration with scripting languages, this would be a dead end.

I'm currently making up integration with scripting languages to make it possible to create vtm applications/components without using C++ at all. The essence is this: the application will consist of a UI layout and scripts attached to UI elements and events. The entire DOM of the application + its current configuration will be available from the scripting run space. The UI layout of the interface will be in XML format (slightly modified) with scripts embedded. It should be like WPF where XAML+CLR. Or like a web frontend - HTML+JavaScript.

All this will be possible after the following tasks are ready

• Integration with scripting run space. See Application Scripting Runtime #393
  • Done: Start/stop external scripting engine.
  • Done: Forwarding arbitrary command blocks to the scripting runspace.
  • Done: Handle output generated by the scripting engine.
  • Forwarding user input to the scripting engine.
  • Access to DOM and events from scripting runspace.
• Keyboard events support in the vtm environment. Currently, there are no keyboard events at all, and all keyboard stream is just forwarded to focused windows as is. See Keyboard-only access #86.
• DOM from XML runtime generator.

[o-sdn-o]

It would be nice to start a window from a python script (using os.system() is an option)

From the moment when internal integration with scripting languages is completed, it will be possible to interact with the environment from outside, i.e. interact with vtm environment objects directly from python3, including creating/closing windows, etc.

[o-sdn-o]

I am interested in making some of the applications in the checklist, mostly interested in the filemanager

I forgot to say that the DirectVT protocol has not yet been completed to create full-fledged applications in the sense of supporting output by an application in several windows. The application should be able to display multiple windows, for example, display modal windows, show window/context menu popups. At the moment, the application can only display its bitmap in one window.

[o-sdn-o]

but I cant test on windows (no windows machines : D )

No problem, I have the capacity to run/debug on all required operating systems.

[o-sdn-o]

I'm also interested in a file manager. Existing TUI file managers lose to GUI file managers. This is at least by the fact that they are locked in one window. They also do not support the Unicode standard well, in terms of grapheme clusters and character widths. This is a consequence of poor terminal support for Unicode. Terminal developers don't want to understand that the application, not the terminal, should determine the character width. The terminal should only assume the character width if the application doesn't specify one. In addition, terminal developers don't want to admit that wide characters have half-parts. Not to mention ligature fragments.

[Vosjedev]

Yes, I am very interested in a console-file manager looking like a graphical file manager (for example dolphin, nautilus, windows exporer.). I am learning to use python3-prompt-toolkit to make apps that would run in the vtm build-in terminal, but makes pop-up windows (also the vtm build-in terminal with a seperate instance of the app running) that would report answers back via (?) using the scipting integration. But your idea about some XML languige sounds more interesting, and I would drop prompt_toolkit and learn it instead when it exists.

(I am currently smiling because of the idea making applications specificaly for vtm, and would scream happiness if I wasn't in a public space right now...)

[Vosjedev]

If you are implementing python or shell scripting integration, I would be happy to test them in my weekends.

Do you know if there are already people making applications in the currenly existing DirectVT protocol, or am I the first who is very exited about making applications dedicated for vtm?

I can also make the store, and maybe host a main repo list on my raspberrypi. (like my already existing packager, vpm written in bash.) It would download a list of packages, with each package entry containing: name|description|git repo|build command or maybe even a a packaging system with package files containing pre-build binaries, like apt, dnf, pacman, etc. I could host the list of download urls for packages on the pi (replace git repo|build command with package url). If you would rather host the packaging list yourself, or use another host for it, I could integrate with that.

[Vosjedev]

I have started testing with an info panel, but it only supports linux xterm based terminals, and only a small group of them... also it glitches out how vtm draws colors (it resets the current escape code all the time, making the background of a vtm terminal disappear). Integration into vtm itself would be nice :). (It is not yet public)

[o-sdn-o]

also it glitches out how vtm draws colors (it resets the current escape code all the time, making the background of a vtm terminal disappear)

I'm very curious. Perhaps the built-in vtm terminal does not support some kind of escape sequence. Please tell me what sequence you use for output or share code block with output function. It would be interesting to analyze such vtm behavior.

[o-sdn-o]

I am learning to use python3-prompt-toolkit to make apps that would run in the vtm build-in terminal, but makes pop-up windows (also the vtm build-in terminal with a seperate instance of the app running) that would report answers back via (?) using the scipting integration.

python-prompt-toolkit is very much in the spirit of what I'm currently implementing. In vtm it will be possible to use not only python.

Among other things, everything done with python-prompt-toolkit should work smoothly without any issues in the built-in vtm terminal.

[o-sdn-o]

Do you know if there are already people making applications in the currently existing DirectVT protocol, or am I the first who is very excited about making applications dedicated for vtm?

The DirectVT protocol is still in development and it is not documented due to the fact that it is still very unstable and often changes. Its main goal is to provide maximum application rendering performance (TUI) and seamless integration with the vtm window manager (smooth & nondestructive app window resizing, mouse hovering, etc.). I think the DirectVT protocol will become stable and ready for use after I make support for keyboard events in vtm. This protocol is part of the not yet ready Desktopio Framework, which will contain everything that I am doing now.

[o-sdn-o]

I can also make the store, and maybe host a main repo list on my raspberrypi. (like my already existing packager, vpm written in bash.) It would download a list of packages, with each package entry containing: name|description|git repo|build command or maybe even a a packaging system with package files containing pre-build binaries, like apt, dnf, pacman, etc. I could host the list of download urls for packages on the pi (replace git repo|build command with package url). If you would rather host the packaging list yourself, or use another host for it, I could integrate with that.

It is still difficult for me to answer in what format the applications will be distributed. Perhaps this will be SSH demo servers evenly distributed throughout the planet (Australia, Japan, EU, US West/East coast) to reduce round trip ping. By logging in to them via the password-free SSH, users will be able to play with the application in real time and, if they like the application, download it. I experimented with this approach and it turned out that vtm works very responsively via SSH from almost anywhere in the world.

[Vosjedev]

python-prompt-toolkit is very much in the spirit of what I'm currently implementing

Thats perfect!

[Vosjedev]

Perhaps this will be SSH demo servers evenly distributed throughout the planet (Australia, Japan, EU, US West/East coast) to reduce round trip ping. By logging in to them via the password-free SSH, users will be able to play with the application in real time and, if they like the application, download it.

Thats an interesting! So how would users know to what ssh server to connect to? Are all apps on the same server? Is there a previeuw button in a sofware center that connects via ssh in a vtm terminal (Maybe the ip is in the packagelist entry)?

I guess it would be possible to make a package format, and download the packages via the same ssh server. I know you can pass a command to run after connect.

Also, I am already using vtm to manage my server via ssh! : D

[o-sdn-o]

Thats an interesting! So how would users know to what ssh server to connect to? Are all apps on the same server? Is there a previeuw button in a sofware center that connects via ssh in a vtm terminal (Maybe the ip is in the packagelist entry)?

A year ago I ran five servers evenly around the world (Sydney, Tokyo, Frankfurt, Richmond, Seattle).
On all five servers, a demo version of the vtm desktop was installed, available when logging in via SSH without a password.
In Frankfurt and Seattle, DNS servers were configured to respond with the ip address closest to the user when resolving the domain address of the SSH server. The servers use a GeoIP database (map IP to geographic coordinates and get the distance between addresses).

The user simply typed ssh vtm@netxs.online in the terminal, the name netxs.online was resolved to the IP address closest to the user host, so the user logged in on the nearest demo-server where vtm was automatically launched as a shell by default. Dozens of users could connect to the same server at the same time and they saw each other's mouse cursors there and could move windows to each other.

[o-sdn-o]

I think the connection to the server with the app store should be clickable at the bottom right of the vtm desktop. This is where the vtm version number label is located.

[o-sdn-o]

Clicking the preview button in the store should open an additional SSH session with a demo of this app.

Or open additional DirectVT window :D

[o-sdn-o]

I will restore this server infrastructure back when the apps and store are ready.

[o-sdn-o]

Someone posted a link to the demo on https://news.ycombinator.com/item?id=24243521 and it was fun.

[Vosjedev]

I think the connection to the server with the app store should be clickable at the bottom right of the vtm desktop.

On the desktop? At all time, or only when the store is open?

Also, what do you think of the idea to make a new package format and mirror them to all servers, downloadable via the ssh session automaticaly?
This could work like the shellcommand

ssh user@server.ip "cat /path/to/package.zip" >> package.zip

Or am I thinking too unix right now?

Or rather an apt-like reposystem like I mentioned earlier, where the store would download a list of packages, with each entry like this:

pkg1-name|example description|https://server.ip/download/pkg1.zip|user@server.ip|cmd-to-preview-app

or maybe use the download via ssh in that.
Users could then add third-party repos to that, like on apt (or any linux pkgmanager).

I would definetely keep the preview, thats a very good idea (wish apt would have that :D).

[Vosjedev]

the server with the app store

Do I understand from this the app store runs on the ssh server, not the local vtm instance?

[o-sdn-o]

Do I understand from this the app store runs on the ssh server, not the local vtm instance?

Exactly.

[o-sdn-o]

On the desktop? At all time, or only when the store is open?

Only when the store is open. I mean a connection link to the store should be placed somewhere in the desktop.

[o-sdn-o]

Also, what do you think of the idea to make a new package format and mirror them to all servers, downloadable via the ssh session automatically?

A new package format is definitely needed. I have not yet thought about it and how distributing and updating packages. There may be all sorts of dependencies and version incompatibilities.

Downloading can be done via SSH or an async DirectVT binary stream.

[o-sdn-o]

Or am I thinking too unix right now?

ssh user@server.ip "cat /path/to/package.zip" >> package.zip

I absolutely don't mind using external operating system components like ssh or wget instead of integrating them into my code. In particular, if I need to connect via SSH, then I just create a process to run the ssh command and pass all the connection parameters to them :D.

[Vosjedev]

What if the button to open the connection to the store would be an entry in the app list?

Also, how would the ssh server notify the local vtm what package to download?

[Vosjedev]

There may be all sorts of dependencies and version incompatibilities.

Ah, I did not think of that yet... maybe the store can talk with the most popular package managers when on a unix system. (Windows does not have a packager, right?)

[o-sdn-o]

What if the button to open the connection to the store would be an entry in the app list?

Good idea. We will make this decision later, when a store prototype is somehow formed. There we can play in real time and choose the appropriate option.

Also, how would the ssh server notify the local vtm what package to download?

When the user clicks on the Download button, the Store running on the remote SSH server initiates the file transfer (either via an OSC sequence or via the DirectVT protocol). Next, a modal window (with file/folder picker) should automatically open with the option of where to save or run to automatically install.

Windows does not have a packager, right?

I'm no expert on the Windows ecosystem, but I think we'll figure it out as we get to this point.

[Vosjedev]

the Store running on the remote SSH server initiates the file transfer (either via an OSC sequence or via the DirectVT protocol).

Ah, that goes above my knowledge. (I just learned to use tcp sockets in python like a month ago). But I guess that could work. It sounds good.

where to save

I guess this means the filemanager should learn to open packages with the local package installer then.

[o-sdn-o]

I guess this means the filemanager should learn to open packages with the local package installer then.

The file picker modal window is a light version of the file manager, a sort of sub module.

[Vosjedev]

So the filemanager should be build-in like the terminal, so that the file picker can be a modal window?

[o-sdn-o]

Perhaps not necessarily. A full-fledged file manager is too heavy.

[Vosjedev]

Would folder bookmarks sync between the dialog an the filemanager? that means vtm should have a bookmark system, or try to read filemanagerbookmark if possible.

[o-sdn-o]

Good point. It looks like there are a lot of things that need to be in sync with the environment. Keyboard shortcuts, folder bookmarks/quick access links, anything else.