| [View Updates][View Threads][View Files][SVN Log][SVN Submitters]| Title: | Default application data manager |  | Synopsis:
Design and implement a default data manager system for applications.
| | Status: | Closed | | Priority: | Medium As prioritized by the OS4 development team | | Category: | system/general | | Description: | The manager shall act as a helper tool for application builders for storing and retrieving default data such as the last used directories, window sizes and such.
Note: The manager is not intended to act as a storage device for general application settings and data, but only to store GUI related default data such as last used path, file, url, window size etc.
Many applications and tools for AmigaOS 4 does not store data such as the last used directory or window position, which can frustrate users who has to reselect directories over and over again.
For example: You may store files downloaded from os4depot in a specific directory and you always unarc them to ram:. But every time you start unarc you have to reselect both the source and destination directory. You can see this missing functionality in most amiga applications and there's neither a common way to do this nor a recommendation/guideline for how to design amigaOS applications in relation to this.
Work for this project does not only center around creating the data manager system but it also includes writing a new chapter for the "AMIGA User Interface Style Guide" that can act as a guideline for what type of default GUI related data an amigaOS 4 application should store and how to use the managers' api.
The work on the manager itself could include three parts:
The following is just a suggestion to illustrate the functionality of the manager. The developer can design the system differently as long as it retains the basic outlined functionality.
| |
1. A virtual device for storing and retrieving the data
It could be built using a single large file in env/envarc but
the virtual device exposes the data as individual entries.
Each entry should contain:
- Application string (such as "unARC")
- Application specific id string (such as "source")
- Datatype (such as integer, float, string ect)
- The stored data
- A flag that says if the data is permanent or temporary
The application string "global" shall be a reserved word for global data.
2. A reaction tool for managing/browsing the stored data
Displaying all data for a specific application.
Ability to delete both individual entities and all data for a specific application
Editing of individual entries
3. A library with standard functions for storing and retrieving commonly used data.
Example functions:
Again the final api does not have to look exactly like this
Entry* getEntry(char *Application, char *ID) - retrieve a specific entry
void setEntry(Entry *entry) - store an entry
void setPath(char *Application, char *ID, char *Path, Boolean IsPermanent) - store a default path
char * getPath(char *Application, char *ID, char *Path) - retrieve a default path
void setWidth(char *Application, char *ID, int Width, Boolean IsPermanent) - set a width
void setHeight(char *Application, char *ID, int Height, Boolean IsPermanent) - set a height
int getWidth(char *Application, char *ID) - retrieve a width
int getHeight(char *Application, char *ID) - retrieve a height
Where Entry is:
char *Application
char *ID
int Datatype
Boolean IsPermanent
void *Data
|
Step 2 functionality could include a standard way for storing data history, such as maintaining a list of the last used paths in an application. With api functions for adding, deleting and retrieving data from such a history list. | | Created by: | orgin | | Created at: | 20080730 17:17 | | Deadline: | Not set | | Finished at: | Not finished | | Last update: | 20140403 12:05 | | Assigned to: | Not assigned |
| Task list for this project |
| ID | Title | Assigned | Progress | Updated | Created by |
|
|
|
