Frequently asked questions
Is Hipe a competitor to X/Wayland?
Hipe is focused on providing presentation, layout and multimedia capabilities normally found within web browser engines, at the level of a desktop environment, while systems like X and Wayland work with hardware input/output devices at a deeper level.
Hipe works on top of a low-level display system rather than replacing it. It runs in an X11 or Wayland session, or directly on the graphics hardware through EGLFS, and leaves hardware devices and drivers to that layer.
Hipe can run within an existing desktop environment, with each Hipe application in its own window, or a Hipe framing manager can fill the screen and be the whole desktop environment.
X11 and Wayland leave presentation to the applications themselves: each one draws its own interface. Hipe does the rendering and layout for every application, and mediates between them.
Will my existing applications work in Hipe?
Not as Hipe applications. Hipe's presentation model is very different to that of traditional window systems, so applications are written for it.
Traditional applications can still be used alongside it. Run hiped within your existing desktop environment and Hipe applications sit next to your other ones. When Hipe runs on X11, a Hipe application such as a framing manager can also embed the windows of legacy X11 applications in its own interface, providing backward compatibility.
Do applications written for Hipe 2.x work with Hipe 3?
They need rebuilding against the Hipe 3 client library.
Does Hipe accept HTML code syntax?
Yes. Hipe uses the same HTML elements and attributes as the web, and CSS style rules. An application can send a block of HTML in a single instruction, or create tags one at a time. Either way, it keeps direct hold of the elements it wants to change later, and manipulates them as the program runs.
What Hipe doesn't do is load web pages: there are no URLs, scripts or page navigation.
Since Hipe is based on WebKit, does Hipe support JavaScript?
No. Hipe's display engine, hipecore, has no JavaScript at all. Websites need scripts because there's often no other way to change a page after it has loaded, but Hipe applications change their elements directly. Leaving scripts out also means no application can run code inside the display server, where it could slow down or compromise every other application.
Do client applications written for Hipe require WebKit, Qt, etc. to run?
No. Client applications written in C or C++ only need to include the Hipe API. Since this is only a very small static library, there are no runtime library dependency requirements for client applications.
Do all client applications written for Hipe need to be written in C/C++?
Although the reference API provided is written in C and C++, the Hipe display server process does not itself depend on client applications being written in any particular language.
Technically, the purpose of the API is to provide a set of functions for connecting to a running instance of Hipe on the local machine and for exchanging instructions with the Hipe server process. As long as these instructions are transmitted to the Hipe socket in the correct format, there is no reason why these functions can't be implemented in other programming languages.
Could the Hipe API be more programmer-friendly?
The reference API provided with Hipe is designed to be as primitive and general as possible. When using the API to develop a client application, you exchange a set of instructions (HIPE_OPs) with the Hipe display server in order to manipulate elements on the screen. This is the level that Hipe itself works at, and you can think of these instructions as a kind of 'assembly language' for Hipe.
Keeping the API as fundamental as possible means that a variety of more abstract application-building toolkits can then be built on top of a stable foundation.
It also means that Hipe's instruction set can remain relatively unchanged as much as possible between versions so that developers have the assurance of a stable platform to build on long-term, and since the API is minimal enough to be statically linked, client applications can be compiled and distributed without runtime dependency hassles (as long as the Hipe server is running on the target machine).