Dingoonity.org

This is more of a general Open Dingux post, but I figured for now it can go here.

So with producing the new Open Dingux, and making it more like a distro, there are plans to standardise folder structures, aswell as used input methods.

Below is my proposal for folder structures, with some suggestions from folks in #dingoonity:

Open Dingux app folder format -- update 4:

<appname>\
   - default.dge
   - default.png
   - metadata.xml

Structure of metadata.xml:


<?xml version="1.0" encoding="UTF-8"?>
<app version="1.0">
    <meta>
        <name>Awesome example app</name>
        <version>1.0</version>
        <date>YYYYMMDD</date>
        <executable>default.dge</executable>
        <icon>default.png</icon>
        <readme>readme.txt</readme>
        <category>Apps</category>
        <description>This is an awesome example application!</description>
        <site>http://dingoonity.org</site>
        <license>GPL</license>
    </meta>
    <person role="author">
        <name>Somebody Someone</name>
        <email>[email protected]</email>
        <site>http://somewhere.com</site>
    </person>
    <person role="porter">
        <name></name>
        <email></email>
        <site></site>
    </person>
</app>

   

So to display the app it would first recursively look for metadata.xml, then list app items based on the following criteria:

if metadata.xml is present
 - <meta> block is parsed for file locations of executable/icon/readme and name
 - <meta> -> <category> is used to classify the type of application, e.g. Games, Emulators, Utilities, etc.
 - <meta> -> <name> is used for the readable name of the application
 - <meta> -> <icon> is used for the icon of the application (if file not found, or <icon> not specified, show a default "executable" icon here)
 - Pressing Y will show more information about the app, such as the remaining fields from <meta> -> description/site, and each of the <person> fields found, classified into author/porter groups.
 - Pressing Y again while displaying information will load the file specified in <meta> -> <readme> if possible



if no metadata.xml is present
 - folder name is used for the app name for this item
 - default.dge is executed when A is pressed
 - default.png is used for icon
 - readme.txt is displayed when pressing Y

The benefits of this structure are that, as seen already in gmenu2x having a standardised "default.dge" method makes adding applications to the menu/launcher being used a lot easier.

With the metadata.xml file we can automate adding names/icons/descriptions and other metadata too. The beauty of this is that if these apps are being used on a system that doesn't support the metadata.xml, the default.dge and the directory name would still be descriptive enough on their own.

edit:

ammended xml structure to add root node, license type, date

This is something we were discussing on irc, just a way to standardise the way people distribute their apps. Currently for people using gmenu2x this has been improved a bit, by the use of the .dge extension, but if we're to improve the menu that is used on OpenDingux, we'll need to impose some better guidelines.

If this structure (it's just folders with files) is used, we could then provide easier customisation of icons, by either replacing the default.png in each app folder, or alternatively using a /usr/share/icons directory and have <app>.png that match /local/apps/<app>/

Point is drag'n'drop without the need for any installation

+1 for mth's idea. This is what the desktop file was designed for