Virtual Object

What is a Virtual Object?

This is a term I've been using in my articles to describe things that are tangible but also virtual. Virtual objects have an appearance on the screen, they may emit sounds, they may be interacted with by clicking on them with the mouse, they be even contain other virtual objects, or be a virtual location, or virtual area instead. Despiste of all this, virtual objects are not real. All of these things I've listed can be part of several different programs, which brings us to the question: what is a virtual object, really?

There is data in the computer, and that data is being displayed to you in some way. A virtual object is a tangible representation of the data.

Example 1: Files and Folders

A good example are files and folders. A folder can have files inside of it. That's common sense. But how does this make any sense, when a folder is just data? How do you put data inside data? Bytes inside bytes? You can not. Instead, we only perceive this is how it works because that's how the data is presented to us. That's the sort of relationship the developers imagined. The same things we can say about folders we could say about categories of posts. How is a post "inside" a category? How does a post "contain" an image? When you click two times to open a file, what are you clicking on, exactly? The file? Is the data inside the file? But the data is stored in the hard disk, so are you clicking on the hard disk? Are you bashing it with your mouse?

What's really happening is that there's a computer program running, such as a file manager, and this program reads the data that says what files are in a folder, and then it reads the data that says what applications are associated with which file types, and then it reads the data that says what icon should it use for a file that is associated with a given application, and then it displays the file as an icon for you.

It looks like a tangible object, a document, a painting, a music disc, but in most cases the "file" icon you see is nothing more than a single text code, its filepath. When you click two times to open a file, the file manager doesn't send a whole document to the application that opens it, it merely tells the application the filepath of the file it was displaying as an icon, e.g. C:\photos\flower.jpg. Then the application asks the operating system to send it the data of the file, using nothing but this text code. What happens after is completely opaque.

The application has no idea where the data of C:\photos\flower.jpg came from. If it's a hard disk, or a SSD, or whatever, as this is all managed by the operating system. As if that wasn't enough, the hard disk also has no idea what a file even is, as this concept comes form a file system such as NFTS that has be installed in the hard disk, before you can even install an operating system like Windows in it. Windows handles the drive letter (C:), which means this NFTS system has some algorithm to turn \photos\flower.jpg into the location of the data of that file in the hard disk.

In practice, the data that composes the filepath \photos\flower.jpg and the data that is associated with this filepath are in different locations in the hard disk. That's why cutting and pasting (or moving) a file is so quick: all it does is change the filepath code associated with a region of the hard disk, while copying and pasting a file is slow: it needs to copy the entire region to a new place. On top of that, the data "inside" the file isn't even actually all of the data of the file! There's also metadata, such as when the file was created, which is stored somewhere else in the file system.

If you use a terminal to list the files in a directory, there will be no icons, just their filenames.

Example 2: The Clipboard

Another great example of a virtual object is the clipboard. The clipboard is where data presumably goes when you cut or copy a text or an image. It's common knowledge: you copy something, it goes to the clipboard, then you paste it, and it comes out of the clipboard. Very simple, right? Makes sense.

Except that if you're on Linux there is one tiny problem.

THE CLIPBOARD DOESN'T EXIST.

You see, for something like the clipboard to exist, there must be something part of the operating system that receives data when you copy it from an application, and sends data when you paste it in another application. That's because, otherwise, if you copied something from application X, closed application X, then tried to paste it in application Y, it wouldn't work because application X's program isn't running anymore, so it has to be managed in the system whose lifetime is longer than any application.

If this sounds familiar to you, that's because that's a real bug. On Linux.

In some cases, instead of actually sending data to a temporary data storage space known as the "clipboard," what ends up actually happening is that application X merely informs the system that it has data that can be copied from, and then, when and if it's pasted in another application, then the system will request the data from application X, and pass it to application Y.

This means that if the code in application X is buggy, then pasting something in application Y can crash or freeze application X when the subprogram that sends the data is executed. If the data was already copied before being pasted, there is no way this could possibly happen when you paste it, as it would happen when you copied it instead.

Note that this depends on the system configuration. For example, if you have something like clipboard history in your system, that can only work if the system immediately requests and stores everything made available for copying instead of waiting until you try to paste, so, in this case, the clipboard does actually exist.