Ubuntu Wiki

• People: EduardChristianDumitrescu

• Launchpad: https://launchpad.net/icy

Objective and Features

The Icy project's objective is to provide a new-generation graphical user interface toolkit. It features multiple back-ends and front-ends, a client-server approach and very small memory footprints for applications.

Features:

• very small memory overhead, probably less than 100KiB per application
• very fast application loading
• multiple back-ends, such as "native-opengl", "Windows API", "Cocoa", "GTK2"
• multiple front-ends, such as "UNIX domain socket + shm", "TCP"

• update: client API written in C

• multi-threaded
• clean and easy-to-use API
• great stability

Detailed features/specifications

• Several back-ends, in two categories: "emulate" and "native" (the names may change in the future).
  • The "emulate" category represents things like "Windows API", "Cocoa" and "GTK2" (as a fallback), in which the toolkit emulates the environment in order to blend in with the native applications.
  • The back-ends in the "native" category are guaranteed to look the same on all tested platforms.
  • Virtual "native" and "emulate" back-ends may be used in order to let the toolkit choose the best back-end from each that would work the best.
• Server-side scripting (javascript and DOM?)
• The toolkit deals with the application's data model and view, so the application does not have to take care of the view at all.

More to come...

Motivation

• Reducing GNOME's memory requirements (if this software ever gets approved by GNOME) (read http://ubuntuforums.org/showthread.php?t=821964 for more information)

• Providing a clean and very easy-to-use API to developers.

• Most GUI toolkits, like GTK or QT, "allow" developers to create aesthetically unpleasant applications. One clean solution to this, that would also help simplifying an application developer's work by a lot is providing the data model and some hints on the UI to the toolkit, and letting the toolkit figure out by itself what the UI should look like. Because of this data-oriented view over the GUI, the toolkit will allow modifying/re-configuring the global/local GUI options in a transparent way - for example, a user may decide that a certain application would be far more user-friendly if it used tabbed toolbars instead of a standard menu. He can instruct the application to use tabbed toolbars, without any change in the application's source code.

Status

The project is in ongoing development. The initial code will be published as soon as possible by Eduard C. Dumitrescu on the project's bazaar branch.

UPDATE: The specification documents are in ongoing progress

Issues

• Xv, XvMC (accelerated video output). Solutions:
  • Make the client library load an additional plug-in that creates a window and embeds it into the server's existing window
    • portability?
  • Create plug-ins for all libraries that use Xv (like GStreamer)
    • bad
    • maybe even impossible
    • portability?
• Rendering OpenGL while using the OpenGL back-end. Solutions:
  • Make the client library load an additional plug-in that creates a window and embeds it into the server's existing window
    • portability?
    • integration: may not work out very well with widget effects
  • Make the application render in an FBO from which the server will read
    • is that even possible? (apparently one cannot share textures among GL contexts from different processes)
    • portability?
  • Use the 'texture_from_pixmap' extension
    • slow?
    • not portable - will have to work out something else for other platforms

Ideas

• Set up events on data structures instead of widgets
• Dynamically-editable persistent GUI (edit-mode?)

If you have ideas or suggestions, add them here (don't forget to credit yourself )