Logo54.224.184.33 
  News  Recent  Stats  Forums  Contact
  Menu
 Username

 Password


   Register here

 Main menu
   BBCode test
 
 Content
   About OpenAmiga
   Guidelines
   Definitions
   SVN Access
   Licenses
   IRC channel
   Links
   ToDo List
   List Content
 
 Projects
   Suggested (0)
   Open (11)
   Assigned (28)
   Pending (0)
   Finished (7)
   Closed (4)
 
 Categories
   Cli (2)
   Datatype (9)
   Drivers (3)
   System (16)
   Workbench (16)
  View project
[View Updates][View Threads][View Files][SVN Log]
Title:Default application data manager
Synopsis:
Design and implement a default data manager system for applications.

Project members:
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  
Open Amiga project website, Created in 2008 by Björn Hagström