Uup - Applications


Initial Thoughts on Applications.

My goal for a UupOS distribution would include a lot of neccessary apps, including Office productivity. Some people argue against this, claiming that it hurts innovation or whatever. In reallity, I feel little useful innovation ever takes place. The same ideas get recycled and feature bloat is the order of the day. This feature bloat results in ever changing file formats just to support stuff no one ever uses.

It's time for that to end. By including E-mail, Calendar, Word processing, spreadsheet, presentation, graphics and database solutions in the distribution my hope is that the focus can be on creating better software that integrates well with the environment, instead of just more of the same old crap.

The goal of the U-Doc system is to allow for good features to be added to the base distribution apps easily, without requiring whole new apps to be created or even for the existing apps to be recompiled.

U-Doc

Open doc had implementation problems... bad. It has been suggested that this was because of the level at which the modules worked. Modules were like mini-apps, so the interface became very modal. "Which module am I working with now?"

The solution would seem to be to have a base application which gets modified (added to) much lower.

Data manipulation vs. display. Data needs to be manipulated and displayed. A module only does one of the other. If it manipulates, it simply takes the data, manipulates it, and returns it to be displayed by the container app.

If it displays, all it does is take raw data, convert it into a displayable image, and returns it to the main app.

Text, Pictures, Movies, Spreadsheet, dynamic images (realtime graphs, etc.)

Module types:
Menu commands Go in Menus, work on selected data.
Tools (for tool pallets) Go on pallets, work on selected data, select data.
Display agents.
Update agents.

Installing Applications

Of course, U-Doc won't handle all types of applications. Here is the install and uninstall architecture of UnobtainumNOS.

All Applications are in "bundles"
Allows a drag&drop install.
If an App needs other parts installed (translators, etc...) these are contained in a sources directory in the bundle. On app launch, the app checks for all required external parts and installs any missing pieces from the sources directory in the bundle.

This allows for all applications to be *self repairing* by *default.*

If you need to save space, you can remove the sources files. It will still check for the parts, but if any are not where they should be, it will give an error to the user saying that the app has become damaged and should be reinstalled. (Assuming the missing files are critical, otherwise just a warning that some features may not work.)

Uninstalling:
Could be an option from inside the app. App would delete its support files and then itself. Then quit.

Could be asked by OS when you delete the file. ("This program used other files still on your system. Would you like to delete them as well?"

Best would be both.

I think two API functions would be added to facilitate this architecture: (These names are unlikely to be the final ones)

U_CheckAppInstall

Takes bundle file ID, options flag
Returns results (OK, Failed & exit, Failed but continue, Failed - insuffiecient privs.)
This call checks for all files on the required list and copies any missing files from the sources folder.
Will alert user with errors.

U_AppUninstall

Takes bundle file ID, options flag (Silent Mode, Ask user)
Before calling, App should close all resources and be ready to exit.
Deletes all extra files and then the app bundle.
App should then imediately exit.