Project codename: Nirvana

1. Introduction
   
   
2. Description
   
   
3. Features
   
   
4. The programmers using Nirvana
   
   
5. The users of Nirvana applications
   
   
6. Scripting feature
   
   
7. GUI widget classes
   
   
8. Input/output classes
   
   
9. Nirvana tools
   
   

1. Goals
   
   
2. Project scheduler
   
   
3. Questions
   
   

1. Preface
   
   
2. Personal opinions
   
   
3. What we need...
   
   
4. Contact us

Nirvana is a new project starting up right now. This site will inform the public about the state of the project, features, ideas and the full concept, so that everybody on the net will be given the chance to send advices and ideas or join the team. First of all, our goal is to find people that are interested in this project, collect concepts that a new GUI system should have. First, we thought about a GUI system for X. Now we plan to make it full portable to any graphical desktop system and operating system. (Here desktop system means the low-level system - e.g. X Window System but not KDE) If you have ever missed an important feature, your desk-top GUI should provide as the GUI system of the next millenium, let it us know, not depending on your skills in programming such a feature.

Nirvana will be a package of libraries and helpful tools. The library will handle a complete gui framework and pop-up menus for applications. A configuration tool will feature users to customize the widget-style, pop-menus and behavior, all Nirvana applications will have. Therefor it will use a technology that keeps important aspects similar to MUI - the MagicUserInterface from SASG - a very popular GUI system on AmigaOS, and an interface that allow users to automate processes via a scripting language. This script will send actions to Nirvana applications as if they were performed via user input directly. Nirvana will be designed to work with several different input and output methods. This will provide easy portability and many new features.

	Creating GUIs will be made easy to figure out for the programmer.
	The user decides the look and feel of the GUI, and all Nirvana applications will behave that way.
	The framework is organized in an object-oriented way. It can be extended with classes, that have been missed up to that point.
	Every GUI drawn in an application window will be size-sensitiv. A user can resize the application window and the framework will be reorganised with its relativ aspects towards the new size.
	Font-sensitiv
	Any action performed through pointer or keyboard will be accessable via a scripting language. You can automatize several Nirvana applications with only one script.
	Nirvana will use the render.library technology. One important feature: Rendering pixmaps to the colormap gotten from the XServer as best it can be.
	A special output class will mirror all GUI output to several displays. This will be usefull when using networked window systems. You can teach somebody by showing him exactly what you do. He will follow you actions on his display.
	Localization of text, locale number formats for different countries.

The programmer will use this library to describe the GUI in an object-oriented way. Several layout features like containers will help creating a framework to the needs of the programmer. You define the relationship between the elements in its relativ size, not the exact positions or sizes in pixels. The widget-style depends on how the user configured it. The exact looks is not to be predicted by the programmer.

	Abstractly described, it will look like Filerequester ( Vertical Group ( Lister, Input Filename, Horizontal Group ( Button Ok, Button Cancel ) ) )
Figure 1 : Example of a file-requester and its abstract description

There will be several attributes that can be added to the elements, like percentages for width and heights towards the parent element and adjustments. But you`ll not be able to determine anykind of font or style attributes or the exact coordinates of any element. One advantage of building up a GUI with Nirvana is that elements can be linked together internally, without extra-code.

In short, what does this mean for your applications? First, you will be confronted with essential layout aspects, not with any graphical characteristics your GUI should have. The layout will be rendered on the users display with design elements they decided. He will accept the application GUI even more than fixed standing designs, a programmer figured out. So it will fit even better in his desktop concept. Second, if you want any internal links in a GUI framework, you decide once and it will be managed by Nirvana. Third, your application can be adopted to any automatization process through Nivana's scripting feature. The user records user input that will be saved to a batch and can be modify with scripting features like loops etc. Forth, the GUI of Nirvana will be very portable to many platforms and desktop systems, and all I/O features will be automatical available. The OS specific stuff will be seperated from the GUI concept. This means it should be possible, if you once compiled your application with Nirvana, it will almost run with newer versions of Nirvana, when there are no dramatically changes of the GUI concept.

1.	an action performed by pointer or keyboard on an element you linked with you routine.
2.	element is linked to activate another element
3.	script sends an event to simulate user input
Figure 2: Methods that invoke your routine

The heart of Nirvana on the user's side will be a configuration tool. With this tool the whole look & feel of any Nirvana GUI element can be customized to the user's preferences. Only once you may want to define global characteristics like button style, fonts to use etc.., and every Nirvana application will behave this way. If the user doesn`t like the global configuration for any particular application, he simply modifies some or all characteristics and saves it explicitely.

Figure 3:Three different user configurations of the same application

Because X is a network transparent window system, the resources for charateristics and the display can be split up to different XServers. (e.g. you want to show your Nivana configuration to your friend on the other side of the world, so he might start an Nirvana client on his XServer with resources from your XServer) Note: This can get complicated,if the XServer displaying the client is not able to display graphics the way it is described in the resources of the other XServer.

user defined
	explicit apps config (highest priority)
	default-config for all apps
system defined
	explicit apps config
	default-config for all apps
	factory-settings (1 bit b/w) (lowest priority)
Table 1 : resources hierarchie on XServer

Every action that is performable via input device (such as keyboard, mouse, tablet...) on a Nirvana GUI, can be recorded or written in a simple script. This solution also allows full automatization between different Nirvana applications. (One recording session on many Nirvana applications)

There is no GUI toolkit that could offer all the features that a programmer might imagine. Therefore, Nirvana is extendable with new GUI element classes, that are built uppon existing style- or widget-classes. Therefore, a file-requester class will be a set of buttons and a lister and mustn't be coded from scratch. These classes will have a configuration method that will be invoked by the configuration tool. This will guarantee centralized configuration for all elements. You can imagine, that widget programming will not be as easy as programming an application under Nirvana.

The i/o classes will provide the link to the OS specific calls and a standarized interface to the hole GUI concept. Porting Nirvana to another Desktop System or OS will only be done here. Because there is a standarized input/output interface to Nirvana with no special relation to any OS or Desktop System, we plan advanced options like mirroring an output to several output classes or having a full session with a friend by merging the inputs too. (e.g. two pointer- and keyboardinputs on both displays) The way parameters will be given to the application (e.g. shell arguments [ANSI C] or tool-types [AmigaOS Workbench] ) will be managed by the input class, so that the application is full portable to any system, that Nirvana supports. Therefore, it will also handle a set of standard startup parameters that all applications will provide. (i/o class, x-server, public screen, etc.)

configuration tool The configuration tool scans through the classes and bind all configuration sections into one tool. script recording tool This tool will record any user input to Nirvana applications and save it to a batch file. This is an useful tool for easy setting up automized processes. script interpreter eventually tcl/tk will be extended with script calls, or a shell command interpreter can be embedded in shell scripts.