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 is designed to work with and compliment the functionality of low-level display servers rather than re-inventing the wheel from scratch. In addition to X and Wayland, it can work on top of any display backend supported by Qt, including direct framebuffering.
In other words: Hipe can run on top of an existing desktop environment (with Hipe-based applications running in separate windows), or a Hipe-based framing manager can occupy the whole screen in order to manage the whole desktop environment. Hipe does not deal with hardware devices or drivers itself, but relies on the underlying functionality of a low-level display system such as X or Wayland if such display systems are used.
X and Wayland are very much focused at the hardware level, with very minimal presentation capabilities (requiring applications to do much of the heavy lifting themselves), while Hipe is focused on high-level rendering and mediation among processes.
Will my existing applications work in Hipe?
No, and that's the point. Hipe's presentation model is very different to that of traditional window systems.
For cases where you need to run both Hipe and traditional applications, we recommend deploying the Hipe display server on top of an existing desktop environment as one possible option. This allows you to run Hipe applications within your existing desktop environment.
Does Hipe accept HTML code syntax?
Not exactly. Since the display engine uses the same document model as a web browser, Hipe uses the same HTML tag elements and attributes as the web, as well as CSS style rules. However, it does not directly parse the HTML syntax used to code a web page. Instead, Hipe provides direct access to the underlying Document Object Model in which HTML tags are stored, and a set of instructions with which to manipulate the document tree, adding tag elements where you require them, then referencing and manipulating those elements as your program runs.
Since Hipe is based on Webkit, does Hipe support JavaScript?
Hipe does not allow the use of JavaScript by client applications. Although JavaScript typically makes sense for websites (since there's often no other way to manipulate elements on a web page after they've loaded), providing the ability to run JavaScript code in Hipe is both unnecessary (Hipe provides direct API-based access to elements on the screen already) and a liability (allowing arbitrary code execution in the display server could potentially allow one client application to compromise the performance of the entire display server).
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 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).